System and method for positioning a mobile drive unit

ABSTRACT

A method for transporting inventory items includes determining an assignment state of a mobile drive unit. The method also includes selecting a location for the mobile drive unit based on the assignment state of the mobile drive unit, in response to determining that the mobile drive unit is not currently completing a task. The method further includes transmitting information to the mobile drive unit identifying the selected location.

TECHNICAL FIELD OF THE INVENTION

This invention relates in general to inventory systems, and moreparticularly to a method and system for efficient management of mobiledrive units within an inventory system.

BACKGROUND OF THE INVENTION

Modern inventory systems, such as those in mail-order warehouses, supplychain distribution centers, airport luggage systems, and custom-ordermanufacturing facilities, face significant challenges in responding torequests for inventory items. As inventory systems grow, the challengesof simultaneously completing a large number of packing, storing, andother inventory-related tasks becomes non-trivial. In inventory systemstasked with responding to large numbers of diverse inventory requests,inefficient utilization of system resources, including space, equipment,and manpower, can result in lower throughput, unacceptably long responsetimes, an ever-increasing backlog of unfinished tasks, and, in general,poor system performance. Additionally, expanding or reducing the size orcapabilities of many inventory systems requires significant changes toexisting infrastructure and equipment. As a result, the cost ofincremental changes to capacity or functionality may be prohibitivelyexpensive limiting the ability of the system to accommodate fluctuationsin system throughput.

SUMMARY OF THE INVENTION

In accordance with the present invention, the disadvantages and problemsassociated with inventory storage have been substantially reduced oreliminated. In particular, a mobile inventory system is provided thatincludes one or more mobile drive units capable of moving any of one ormore inventory holders between locations within a physical spaceassociated with the mobile inventory system.

In accordance with one embodiment of the present invention, a method fortransporting inventory items includes determining an assignment state ofa mobile drive unit. The method also includes selecting a location forthe mobile drive unit based on the assignment state of the mobile driveunit, in response to determining that the mobile drive unit is notcurrently completing a task. The method further includes transmittinginformation to the mobile drive unit identifying the selected location.

In accordance with another embodiment of the present invention, a systemfor transporting inventory items includes a mobile drive unit, aplurality of inventory holders, and a management module. The managementmodule determines an assignment state of the mobile drive unit. Inresponse to determining that the mobile drive unit is not currentlycompleting a task, the management module selects a location for themobile drive unit based on the assignment state of the mobile driveunit. The management module additionally transmits information to themobile drive unit identifying the selected location.

Technical advantages of certain embodiments of the present inventioninclude the ability to optimize the use of space, equipment, andmanpower to complete inventory related-tasks. Additionally, particularembodiments may utilize a plurality of independently-operating driveunits, each capable of accessing and moving a particular inventory itemstored anywhere within the inventory system. Such a configuration mayprovide the ability for the inventory system to access in an arbitraryorder any item stored in the system and allow for parallel completion ofmultiple inventory tasks in a system that is easily scalable andportable. Other technical advantages of certain embodiments of thepresent invention include providing a flexible and scalable inventorystorage solution that can be easily adapted to accommodate system growthand modification and allocating system-level resources in an efficientmanner to the completion of individual tasks.

Other technical advantages of the present invention will be readilyapparent to one skilled in the art from the following figures,descriptions, and claims. Moreover, while specific advantages have beenenumerated above, various embodiments may include all, some, or none ofthe enumerated advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and itsadvantages, reference is now made to the following description, taken inconjunction with the accompanying drawings, in which:

FIG. 1 illustrates components of an inventory system according to aparticular embodiment;

FIG. 2 illustrates in greater detail the components of an examplemanagement module that may be utilized in particular embodiments of theinventory system shown in FIG. 1;

FIGS. 3A and 3B illustrate in greater detail an example mobile driveunit that may be utilized in particular embodiments of the inventorysystem shown in FIG. 1;

FIG. 4 illustrates in greater detail an example inventory holder thatmay be utilized in particular embodiments of the inventory system shownin FIG. 1;

FIG. 5 illustrates an example of routing and reservation techniques thatmay be utilized by the management module in particular embodiments ofthe inventory system illustrated in FIG. 1;

FIG. 6 is a flowchart detailing example operation of a particularembodiment of the management module in managing movement of mobile driveunits in the inventory system;

FIG. 7 illustrates an example embodiment of the inventory system that iscapable of planning paths for a requesting mobile drive unit based onthe mobile drive unit's current state;

FIG. 8 is a flowchart detailing example operation of a particularembodiment of the management module in implementing the techniquesdescribed in FIG. 7;

FIG. 9 illustrates an example embodiment of the inventory system capableof optimizing the placement of mobile drive units based on theirassignment state;

FIG. 10 illustrates an example embodiment of the inventory systemcapable of optimizing the placement of mobile drive units based on theircapability state;

FIG. 11 is a flowchart detailing example operation of a particularembodiment of the management module in implementing the techniquesdescribed in FIG. 9;

FIGS. 12A-12E illustrate an example of coordinated movement that may beexecuted by particular embodiments of the mobile drive unit;

FIG. 13 is a flowchart detailing example operation of the managementmodule in facilitating the coordinated movement illustrated in FIGS.12A-12E;

FIG. 14 is a flowchart detailing example operation of a mobile driveunit in implementing the coordinated movement illustrated in FIGS.12A-12E;

FIG. 15 illustrates an example embodiment of the inventory system thatincludes conveyance equipment capable of transporting mobile drive unitsbetween separate portions of the workspace;

FIG. 16 illustrates techniques that the inventory system may use inassigning tasks based on the availability and characteristics ofconveyance equipment;

FIG. 17 is a flowchart illustrating the operation of a particularembodiment of resource scheduling module in selecting paths for mobiledrive units in a workspace that utilizes drive lifts;

FIG. 18 illustrates an example embodiment of the inventory system thatincludes one or more rotation areas for the rotation of inventoryholders;

FIGS. 19A-19E illustrate example operation of a particular embodiment ofmobile drive unit in utilizing a rotation area; and

FIGS. 20A-20F illustrate example operation of a particular embodiment ofmobile drive unit while transporting inventory holders outside of therotation areas illustrated in FIGS. 18 and 19A-19E.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates the contents of an inventory system 10. Inventorysystem 10 includes a management module 15, one or more mobile driveunits 20, one or more inventory holders 30, and one or more inventorystations 50. Mobile drive units 20 transport inventory holders 30between points within a workspace 70 in response to commandscommunicated by management module 15. Each inventory holder 30 storesone or more types of inventory items. As a result, inventory system 10is capable of moving inventory items between locations within workspace70 to facilitate the entry, processing, and/or removal of inventoryitems from inventory system 10 and the completion of other tasksinvolving inventory items.

Management module 15 assigns tasks to appropriate components ofinventory system 10 and coordinates operation of the various componentsin completing the tasks. These tasks may relate not only to the movementand processing of inventory items, but also to the management andmaintenance of the components of inventory system 10. For example,management module 15 may assign portions of workspace 70 as parkingspaces for mobile drive units 20, the scheduled recharge or replacementof mobile drive unit batteries, the storage of empty inventory holders30, or any other operations associated with the functionality supportedby inventory system 10 and its various components. Management module 15may select components of inventory system 10 to perform these tasks andcommunicate appropriate commands and/or data to the selected componentsto facilitate completion of these operations. Although shown in FIG. 1as a single, discrete component, management module 15 may representmultiple components and may represent or include portions of mobiledrive units 20 or other elements of inventory system 10. As a result,any or all of the interaction between a particular mobile drive unit 20and management module 15 that is described below may, in particularembodiments, represent peer-to-peer communication between that mobiledrive unit 20 and one or more other mobile drive units 20. The contentsand operation of an example embodiment of management module 15 arediscussed further below with respect to FIG. 2.

Mobile drive units 20 move inventory holders 30 between locations withinworkspace 70. Mobile drive units 20 may represent any devices orcomponents appropriate for use in inventory system 10 based on thecharacteristics and configuration of inventory holders 30 and/or otherelements of inventory system 10. In a particular embodiment of inventorysystem 10, mobile drive units 20 represent independent, self-powereddevices configured to freely move about workspace 70. In alternativeembodiments, mobile drive units 20 represent elements of a trackedinventory system 10 configured to move inventory holder 30 along tracks,rails, cables, crane system, or other guidance or support elementstraversing workspace 70. In such an embodiment, mobile drive units 20may receive power and/or support through a connection to the guidanceelements, such as a powered rail. Additionally, in particularembodiments of inventory system 10 mobile drive units 20 may beconfigured to utilize alternative conveyance equipment to move withinworkspace 70 and/or between separate portions of workspace 70. Thecontents and operation of an example embodiment of a mobile drive unit20 are discussed further below with respect to FIGS. 3A and 3B.

Additionally, mobile drive units 20 may be capable of communicating withmanagement module 15 to receive information identifying selectedinventory holders 30, transmit the locations of mobile drive units 20,or exchange any other suitable information to be used by managementmodule 15 or mobile drive units 20 during operation. Mobile drive units20 may communicate with management module 15 wirelessly, using wiredconnections between mobile drive units 20 and management module 15,and/or in any other appropriate manner. As one example, particularembodiments of mobile drive unit 20 may communicate with managementmodule 15 and/or with one another using 802.11, Bluetooth, or InfraredData Association (IrDA) standards, or any other appropriate wirelesscommunication protocol. As another example, in a tracked inventorysystem 10, tracks or other guidance elements upon which mobile driveunits 20 move may be wired to facilitate communication between mobiledrive units 20 and other components of inventory system 10. Furthermore,as noted above, management module 15 may include components ofindividual mobile drive units 20. Thus, for the purposes of thisdescription and the claims that follow, communication between managementmodule 15 and a particular mobile drive unit 20 may representcommunication between components of a particular mobile drive unit 20.In general, mobile drive units 20 may be powered, propelled, andcontrolled in any manner appropriate based on the configuration andcharacteristics of inventory system 10.

Inventory holders 30 store inventory items. In a particular embodiment,inventory holders 30 include multiple storage bins with each storage bincapable of holding one or more types of inventory items. Inventoryholders 30 are capable of being carried, rolled, and/or otherwise movedby mobile drive units 20. In particular embodiments, inventory holder 30may provide additional propulsion to supplement that provided by mobiledrive unit 20 when moving inventory holder 30.

Additionally, each inventory holder 30 may include a plurality of faces,and each bin may be accessible through one or more faces of theinventory holder 30. For example, in a particular embodiment, inventoryholder 30 includes four faces. In such an embodiment, bins located at acorner of two faces may be accessible through either of those two faces,while each of the other bins is accessible through an opening in one ofthe four faces. Mobile drive unit 20 may be configured to rotateinventory holder 30 at appropriate times to present a particular faceand the bins associated with that face to an operator or othercomponents of inventory system 10. The contents and operation of anexample embodiment of an inventory holder 30 are discussed further belowwith respect to FIG. 4.

Inventory items represent any objects suitable for storage, retrieval,and/or processing in an automated inventory system 10. For the purposesof this description, “inventory items” may represent any one or moreobjects of a particular type that are stored in inventory system 10.Thus, a particular inventory holder 30 is currently “storing” aparticular inventory item if the inventory holder 30 currently holds oneor more units of that type. As one example, inventory system 10 mayrepresent a mail order warehouse facility, and inventory items mayrepresent merchandise stored in the warehouse facility. Duringoperation, mobile drive units 20 may retrieve inventory holders 30containing one or more inventory items requested in an order to bepacked for delivery to a customer or inventory holders 30 carryingpallets containing aggregated collections of inventory items forshipment. Moreover, in particular embodiments of inventory system 10,boxes containing completed orders may themselves represent inventoryitems.

As another example, inventory system 10 may represent amerchandise-return facility. In such an embodiment, inventory items mayrepresent merchandise returned by customers. Units of these inventoryitems may be stored in inventory holders 30 when received at thefacility. At appropriate times, a large number of units may be removedfrom a particular inventory holder 30 and packed for shipment back to awarehouse or other facility. For example, individual units of aparticular inventory item may be received and stored in inventoryholders 30 until a threshold number of units of that inventory item havebeen received. Mobile drive unit 20 may be tasked with retrieving aninventory holder 30 in this state. A pallet may then be packed withinventory items removed from that inventory holder 30 and shipped toanother facility, such as a mail-order warehouse.

As another example, inventory system 10 may represent an airport luggagefacility. In such an embodiment, inventory items may represent pieces ofluggage stored in the luggage facility. Mobile drive units 20 mayretrieve inventory holders 30 storing luggage arriving and/or departingon particular flights or luggage destined for particular types ofprocessing, such as x-ray or manual searching.

As yet another example, inventory system 10 may represent amanufacturing facility, and inventory items may represent individualcomponents of a manufacturing kit. More specifically, inventory itemsmay represent components intended for inclusion in an assembled product,such as electronic components for a customized computer system. In suchan embodiment, inventory system 10 may retrieve particular componentsidentified by a specification associated with an order for the productso that a customized version of the product can be built. Although anumber of example embodiments are described, inventory system 10 may, ingeneral, represent any suitable facility or system for storing andprocessing inventory items, and inventory items may represent objects ofany type suitable for storage, retrieval, and/or processing in aparticular inventory system 10.

In particular embodiments, inventory system 10 may also include one ormore inventory stations 50. Inventory stations 50 represent locationsdesignated for the completion of particular tasks involving inventoryitems. Such tasks may include the removal of inventory items frominventory holders 30, the introduction of inventory items into inventoryholders 30, the counting of inventory items in inventory holders 30, thedecomposition of inventory items (e.g. from pallet- or case-sized groupsto individual inventory items), and/or the processing or handling ofinventory items in any other suitable manner. In particular embodiments,inventory stations 50 may just represent the physical locations where aparticular task involving inventory items can be completed withinworkspace 70. In alternative embodiments, inventory stations 50 mayrepresent both the physical location and also any appropriate equipmentfor processing or handling inventory items, such as scanners formonitoring the flow of inventory items in and out of inventory system10, communication interfaces for communicating with management module15, and/or any other suitable components. Inventory stations 50 may becontrolled, entirely or in part, by human operators or may be fullyautomated. Moreover, the human or automated operators of inventorystations 50 may be capable of performing certain tasks to inventoryitems, such as packing or counting inventory items, as part of theoperation of inventory system 10.

Workspace 70 represents an area associated with inventory system 10 inwhich mobile drive units 20 can move and/or inventory holders 30 can bestored. For example, workspace 70 may represent all or part of the floorof a mail-order warehouse in which inventory system 10 operates.Although FIG. 1 shows, for the purposes of illustration, an embodimentof inventory system 10 in which workspace 70 includes a fixed,predetermined, and finite physical space, particular embodiments ofinventory system 10 may include mobile drive units 20 and inventoryholders 30 that are configured to operate within a workspace 70 that isof variable dimensions and/or an arbitrary geometry. While FIG. 1illustrates a particular embodiment of inventory system 10 in whichworkspace 70 is entirely enclosed in a building, alternative embodimentsmay utilize workspaces 70 in which some or all of the workspace 70 islocated outdoors, within a vehicle (such as a cargo ship), or otherwiseunconstrained by any fixed structure.

Moreover, in particular embodiments, workspace 70 may include multipleportions that are physically separated from one another, including butnot limited to separate floors, rooms, buildings, and/or portionsdivided in any other suitable manner. Mobile drive units 20 may beconfigured to utilize alternative conveyance equipment such as verticalor horizontal conveyors, trucks, ferries, gondolas, escalators, and/orother appropriate equipment suitable to convey mobile drive units 20between separate portions of workspace 70.

In particular embodiments, as discussed in greater detail below withrespect to FIG. 5, workspace 70 is associated with a grid (shown in FIG.5 as grid 12) that connects a plurality of points within workspace 70.This grid may divide workspace 70 into a number of portions referred toas cells 14. Cells 14 may square, rectangular, polygonal, and/or of anyother appropriate shape. In particular embodiments, workspace 70 may beportioned so that cells 14 have dimensions slightly larger thaninventory holders 30. This may allow inventory system 10 to utilize aworkspace 70 of minimal size without collisions occurring betweeninventory holders 30 being transported through neighboring cells 14. Ingeneral, however, cells 14 may sized in any manner appropriate based onthe configuration and characteristics of the components of inventorysystem 10. Additionally, workspace 70 may utilize an irregular grid 12in which size and/or shape may vary from cell 14 to cell 14.

In operation, management module 15 selects appropriate components tocomplete particular tasks and transmits task assignments 18 to theselected components to trigger completion of the relevant tasks. Eachtask assignment 18 defines one or more tasks to be completed by aparticular component. These tasks may relate to the retrieval, storage,replenishment, and counting of inventory items and/or the management ofmobile drive units 20, inventory holders 30, inventory stations 50 andother components of inventory system 10. Depending on the component andthe task to be completed, a particular task assignment 18 may identifylocations, components, and/or actions associated with the correspondingtask and/or any other appropriate information to be used by the relevantcomponent in completing the assigned task.

In particular embodiments, management module 15 generates taskassignments 18 based, in part, on inventory requests that managementmodule 15 receives from other components of inventory system 10 and/orfrom external components in communication with management module 15.These inventory requests identify particular operations to be completedinvolving inventory items stored or to be stored within inventory system10 and may represent communication of any suitable form. For example, inparticular embodiments, an inventory request may represent a shippingorder specifying particular inventory items that have been purchased bya customer and that are to be retrieved from inventory system 10 forshipment to the customer. Management module 15 may also generate taskassignments 18 independently of such inventory requests, as part of theoverall management and maintenance of inventory system 10. For example,management module 15 may generate task assignments 18 in response to theoccurrence of a particular event (e.g., in response to a mobile driveunit 20 requesting a space to park), according to a predeterminedschedule (e.g., as part of a daily start-up routine), or at anyappropriate time based on the configuration and characteristics ofinventory system 10. After generating one or more task assignments 18,management module 15 transmits the generated task assignments 18 toappropriate components for completion of the corresponding task. Therelevant components then execute their assigned tasks.

With respect to mobile drive units 20 specifically, management module 15may, in particular embodiments, communicate task assignments 18 toselected mobile drive units 20 that identify one or more destinationsfor the selected mobile drive units 20. Management module 15 may selecta mobile drive unit 20 to assign the relevant task based on the locationor state of the selected mobile drive unit 20, an indication that theselected mobile drive unit 20 has completed a previously-assigned task,a predetermined schedule, and/or any other suitable consideration. Thesedestinations may be associated with an inventory request the managementmodule 15 is executing or a management objective the management module15 is attempting to fulfill. For example, the task assignment may definethe location of an inventory holder 30 to be retrieved, an inventorystation 50 to be visited, a storage location where the mobile drive unit20 should park until receiving another task, or a location associatedwith any other task appropriate based on the configuration,characteristics, and/or state of inventory system 10, as a whole, orindividual components of inventory system 10. For example, in particularembodiments, such decisions may be based on the popularity of particularinventory items, the staffing of a particular inventory station 50, thetasks currently assigned to a particular mobile drive unit 20, and/orany other appropriate considerations.

As part of completing these tasks mobile drive units 20 may dock withand transport inventory holders 30 within workspace 70. Mobile driveunits 20 may dock with inventory holders 30 by connecting to, lifting,and/or otherwise interacting with inventory holders 30 in any othersuitable manner so that, when docked, mobile drive units 20 are coupledto and/or support inventory holders 30 and can move inventory holders 30within workspace 70. While the description below focuses on particularembodiments of mobile drive unit 20 and inventory holder 30 that areconfigured to dock in a particular manner, alternative embodiments ofmobile drive unit 20 and inventory holder 30 may be configured to dockin any manner suitable to allow mobile drive unit 20 to move inventoryholder 30 within workspace 70. Additionally, as noted below, inparticular embodiments, mobile drive units 20 represent all or portionsof inventory holders 30. In such embodiments, mobile drive units 20 maynot dock with inventory holders 30 before transporting inventory holders30 and/or mobile drive units 20 may each remain continually docked witha particular inventory holder 30.

While the appropriate components of inventory system 10 completeassigned tasks, management module 15 may interact with the relevantcomponents to ensure the efficient use of space, equipment, manpower,and other resources available to inventory system 10. As one specificexample of such interaction, management module 15 is responsible, inparticular embodiments, for planning the paths mobile drive units 20take when moving within workspace 70 and for allocating use of aparticular portion of workspace 70 to a particular mobile drive unit 20for purposes of completing an assigned task. In such embodiments, mobiledrive units 20 may, in response to being assigned a task, request a pathto a particular destination associated with the task. Moreover, whilethe description below focuses on one or more embodiments in which mobiledrive unit 20 requests paths from management module 15, mobile driveunit 20 may, in alternative embodiments, generate its own paths.

Management module 15 may select a path between the current location ofthe requesting mobile drive unit 20 and the requested destination andcommunicate information identifying this path to the mobile drive unit20. Management module 15 may utilize knowledge of current congestion,historical traffic trends, task prioritization, and/or other appropriateconsiderations to select an optimal path for the requesting mobile driveunit 20 to take in getting to the destination. Additionally, in planningthe path (or in assigning tasks), management module 15 may make informeddecisions regarding the use of lifts, conveyors, ramps, tunnels, and/orother conveyance equipment or features of workspace 70 to facilitate themovement of the relevant mobile drive unit 20, as discussed below withrespect to FIGS. 15-17.

After receiving a path from management module 15, the requesting mobiledrive unit 20 may then move to the destination, traversing the path in asegment-by-segment manner. Before beginning a particular segment, therelevant mobile drive unit 20 may request permission to use the segmentfrom management module 15. As a result, management module 15 may reservethe segment for use of that mobile drive unit 20. As a result,management module 15 may also be responsible for resolving competingrequests to the use of a particular portion of workspace 70. An exampleimplementation of this process is discussed in greater detail below inconjunction with FIG. 5.

In addition, components of inventory system 10 may provide informationto management module 15 regarding their current state, other componentsof inventory system 10 with which they are interacting, and/or otherconditions relevant to the operation of inventory system 10. This mayallow management module 15 to utilize feedback from the relevantcomponents to update algorithm parameters, adjust policies, or otherwisemodify its decision-making to respond to changes in operating conditionsor the occurrence of particular events.

In addition, while management module 15 may be configured to managevarious aspects of the operation of the components of inventory system10, in particular embodiments, the components themselves may also beresponsible for decision-making relating to certain aspects of theiroperation, thereby reducing the processing load on management module 15.In particular, individual components may be configured to independentlyrespond to certain localized circumstances in a manner that allows thesecomponents to improve their effectiveness without reducing the overallefficiency of inventory system 10. As one example, under certainconditions, management module 15 may modify its policies regardingsegment reservations to permit the simultaneous movement of multiplemobile drive units 20 in a particular cell 14 of workspace 70, allowingthe relevant mobile drive units 20 to operate in closer proximity to oneanother than would otherwise be permitted. When operating under suchconditions, management module 15 may rely on the independentdecision-making of the mobile drive units 20 to prevent collisions.FIGS. 12A-12E, 13, and 14 illustrate an example of mobile drive units 20operating under such conditions.

Thus, based on its knowledge of the location, current state, and/orother characteristics of the various components of inventory system 10and an awareness of all the tasks currently being completed, managementmodule 15 can generate tasks, allot usage of system resources, andotherwise direct the completion of tasks by the individual components ina manner that optimizes operation from a system-wide perspective.Moreover, by relying on a combination of both centralized, system-widemanagement and localized, component-specific decision-making, particularembodiments of inventory system 10 may be able to support a number oftechniques for efficiently executing various aspects of the operation ofinventory system 10. As a result, particular embodiments of managementmodule 15 may, by implementing one or more management techniquesdescribed below, enhance the efficiency of inventory system 10 and/orprovide other operational benefits.

FIGS. 2-4 illustrate in greater detail the contents of particularembodiments of management module 15, mobile drive unit 20, and inventoryholder 30, respectively. FIGS. 5-20 illustrate examples of specificmanagement techniques that may be supported by certain embodiments ofinventory system 10. Although FIGS. 2-4 describe particular exampleembodiments of management module 15, mobile drive unit 20, and inventoryholder 30 the techniques described with respect to FIGS. 5-20 may beutilized in inventory systems 10 utilizing any appropriate type ofcomponents.

FIG. 2 illustrates in greater detail the components of a particularembodiment of management module 15. As shown, the example embodimentincludes a resource scheduling module 92, a route planning module 94, asegment reservation module 96, a communication interface module 98, aprocessor 90, and a memory 91. Management module 15 may represent asingle component, multiple components located at a central locationwithin inventory system 10, or multiple components distributedthroughout inventory system 10. For example, management module 15 mayrepresent components of one or more mobile drive units 20 that arecapable of communicating information between the mobile drive units 20and coordinating the movement of mobile drive units 20 within workspace70. In general, management module 15 may include any appropriatecombination of hardware and/or software suitable to provide thedescribed functionality.

Processor 90 is operable to execute instructions associated with thefunctionality provided by management module 15. Processor 90 maycomprise one or more general purpose computers, dedicatedmicroprocessors, or other processing devices capable of communicatingelectronic information. Examples of processor 90 include one or moreapplication-specific integrated circuits (ASICs), field-programmablegate arrays (FPGAs), digital signal processors (DSPs) and any othersuitable specific or general purpose processors.

Memory 91 stores processor instructions, inventory requests, reservationinformation, state information for the various components of inventorysystem 10 and/or any other appropriate values, parameters, orinformation utilized by management module 15 during operation. Memory 91may represent any collection and arrangement of volatile ornon-volatile, local or remote devices suitable for storing data.Examples of memory 91 include, but are not limited to, random accessmemory (RAM) devices, read only memory (ROM) devices, magnetic storagedevices, optical storage devices, or any other suitable data storagedevices.

Resource scheduling module 92 processes received inventory requests andgenerates one or more assigned tasks to be completed by the componentsof inventory system 10. Resource scheduling module 92 may also selectone or more appropriate components for completing the assigned tasksand, using communication interface module 98, communicate the assignedtasks to the relevant components. Additionally, resource schedulingmodule 92 may also be responsible for generating assigned tasksassociated with various management operations, such as prompting mobiledrive units 20 to recharge batteries or have batteries replaced,instructing inactive mobile drive units 20 to park in a location outsidethe anticipated traffic flow or a location near the anticipated site offuture tasks, and/or directing mobile drive units 20 selected for repairor maintenance to move towards a designated maintenance station.

Route planning module 94 receives route requests from mobile drive units20. These route requests identify one or more destinations associatedwith a task the requesting mobile drive unit 20 is executing. Inresponse to receiving a route request, route planning module 94generates a path to one or more destinations identified in the routerequest. Route planning module 94 may implement any appropriatealgorithms utilizing any appropriate parameters, factors, and/orconsiderations to determine the appropriate path. After generating anappropriate path, route planning module 94 transmits a route responseidentifying the generated path to the requesting mobile drive unit 20using communication interface module 98. This process is discussed ingreater detail below with respect to FIG. 5.

Segment reservation module 96 receives reservation requests from mobiledrive units 20 attempting to move along paths generated by routeplanning module 94. These reservation requests request the use of aparticular portion of workspace 70 (referred to herein as a “segment”)to allow the requesting mobile drive unit 20 to avoid collisions withother mobile drive units 20 while moving across the reserved segment. Inresponse to received reservation requests, segment reservation module 96transmits a reservation response granting or denying the reservationrequest to the requesting mobile drive unit 20 using the communicationinterface module 98. This process is also discussed in greater detailbelow with respect to FIG. 5.

Communication interface module 98 facilitates communication betweenmanagement module 15 and other components of inventory system 10,including reservation responses, reservation requests, route requests,route responses, and task assignments. These reservation responses,reservation requests, route requests, route responses, and taskassignments may represent communication of any form appropriate based onthe capabilities of management module 15 and may include any suitableinformation. Depending on the configuration of management module 15,communication interface module 98 may be responsible for facilitatingeither or both of wired and wireless communication between managementmodule 15 and the various components of inventory system 10. Inparticular embodiments, management module 15 may communicate usingcommunication protocols such as 802.11, Bluetooth, or Infrared DataAssociation (IrDA) standards. Furthermore, management module 15 may, inparticular embodiments, represent a portion of mobile drive unit 20 orother components of inventory system 10. In such embodiments,communication interface module 98 may facilitate communication betweenmanagement module 15 and other parts of the same system component.

In general, resource scheduling module 92, route planning module 94,segment reservation module 96, and communication interface module 98 mayeach represent any appropriate hardware and/or software suitable toprovide the described functionality. In addition, as noted above,management module 15 may, in particular embodiments, represent multipledifferent discrete components and any or all of resource schedulingmodule 92, route planning module 94, segment reservation module 96, andcommunication interface module 98 may represent components physicallyseparate from the remaining elements of management module 15. Moreover,any two or more of resource scheduling module 92, route planning module94, segment reservation module 96, and communication interface module 98may share common components. For example, in particular embodiments,resource scheduling module 92, route planning module 94, segmentreservation module 96 represent computer processes executing onprocessor 90 and communication interface module 98 comprises a wirelesstransmitter, a wireless receiver, and a related computer processexecuting on processor 90.

FIGS. 3A and 3B illustrate in greater detail the components of aparticular embodiment of mobile drive unit 20. In particular, FIGS. 3Aand 3B include a front and side view of an example mobile drive unit 20.Mobile drive unit 20 includes a docking head 110, a drive module 120, adocking actuator 130, and a control module 170. Additionally, mobiledrive unit 20 may include one or more sensors configured to detect ordetermine the location of mobile drive unit 20, inventory holder 30,and/or other appropriate elements of inventory system 10. In theillustrated embodiment, mobile drive unit 20 includes a position sensor140, a holder sensor 150, an obstacle sensor 160, and an identificationsignal transmitter 162.

Docking head 110, in particular embodiments of mobile drive unit 20,couples mobile drive unit 20 to inventory holder 30 and/or supportsinventory holder 30 when mobile drive unit 20 is docked to inventoryholder 30. Docking head 110 may additionally allow mobile drive unit 20to maneuver inventory holder 30, such as by lifting inventory holder 30,propelling inventory holder 30, rotating inventory holder 30, and/ormoving inventory holder 30 in any other appropriate manner. Docking head110 may also include any appropriate combination of components, such asribs, spikes, and/or corrugations, to facilitate such manipulation ofinventory holder 30. For example, in particular embodiments, dockinghead 110 may include a high-friction portion that abuts a portion ofinventory holder 30 while mobile drive unit 20 is docked to inventoryholder 30. In such embodiments, frictional forces created between thehigh-friction portion of docking head 110 and a surface of inventoryholder 30 may induce translational and rotational movement in inventoryholder 30 when docking head 110 moves and rotates, respectively. As aresult, mobile drive unit 20 may be able to manipulate inventory holder30 by moving or rotating docking head 110, either independently or as apart of the movement of mobile drive unit 20 as a whole.

Drive module 120 propels mobile drive unit 20 and, when mobile driveunit 20 and inventory holder 30 are docked, inventory holder 30. Drivemodule 120 may represent any appropriate collection of componentsoperable to propel drive module 120. For example, in the illustratedembodiment, drive module 120 includes motorized axle 122, a pair ofmotorized wheels 124, and a pair of stabilizing wheels 126. Onemotorized wheel 124 is located at each end of motorized axle 122, andone stabilizing wheel 126 is positioned at each end of mobile drive unit20.

Docking actuator 130 moves docking head 110 towards inventory holder 30to facilitate docking of mobile drive unit 20 and inventory holder 30.Docking actuator 130 may also be capable of adjusting the position ororientation of docking head 110 in other suitable manners to facilitatedocking. Docking actuator 130 may include any appropriate components,based on the configuration of mobile drive unit 20 and inventory holder30, for moving docking head 110 or otherwise adjusting the position ororientation of docking head 110. For example, in the illustratedembodiment, docking actuator 130 includes a motorized shaft (not shown)attached to the center of docking head 110. The motorized shaft isoperable to lift docking head 110 as appropriate for docking withinventory holder 30.

Drive module 120 may be configured to propel mobile drive unit 20 in anyappropriate manner. For example, in the illustrated embodiment,motorized wheels 124 are operable to rotate in a first direction topropel mobile drive unit 20 in a forward direction. Motorized wheels 124are also operable to rotate in a second direction to propel mobile driveunit 20 in a backward direction. In the illustrated embodiment, drivemodule 120 is also configured to rotate mobile drive unit 20 by rotatingmotorized wheels 124 in different directions from one another or byrotating motorized wheels 124 at different speed from one another.

Position sensor 140 represents one or more sensors, detectors, or othercomponents suitable for determining the location of mobile drive unit 20in any appropriate manner. For example, in particular embodiments, theworkspace 70 associated with inventory system 10 includes a number offiducial marks that mark points on a two-dimensional grid that coversall or a portion of workspace 70. In such embodiments, position sensor140 may include a camera and suitable image- and/or video-processingcomponents, such as an appropriately-programmed digital signalprocessor, to allow position sensor 140 to detect fiducial marks withinthe camera's field of view. Control module 170 may store locationinformation that position sensor 140 updates as position sensor 140detects fiducial marks. As a result, position sensor 140 may utilizefiducial marks to maintain an accurate indication of the location mobiledrive unit 20 and to aid in navigation when moving within workspace 70.

Holder sensor 150 represents one or more sensors, detectors, or othercomponents suitable for detecting inventory holder 30 and/ordetermining, in any appropriate manner, the location of inventory holder30, as an absolute location or as a position relative to mobile driveunit 20. Holder sensor 150 may be capable of detecting the location of aparticular portion of inventory holder 30 or inventory holder 30 as awhole. Mobile drive unit 20 may then use the detected information fordocking with or otherwise interacting with inventory holder 30.

Obstacle sensor 160 represents one or more sensors capable of detectingobjects located in one or more different directions in which mobiledrive unit 20 is capable of moving. Obstacle sensor 160 may utilize anyappropriate components and techniques, including optical, radar, sonar,pressure-sensing and/or other types of detection devices appropriate todetect objects located in the direction of travel of mobile drive unit20. In particular embodiments, obstacle sensor 160 may transmitinformation describing objects it detects to control module 170 to beused by control module 170 to identify obstacles and to take appropriateremedial actions to prevent mobile drive unit 20 from colliding withobstacles and/or other objects.

Obstacle sensor 160 may also detect signals transmitted by other mobiledrive units 20 operating in the vicinity of the illustrated mobile driveunit 20. For example, in particular embodiments of inventory system 10,one or more mobile drive units 20 may include an identification signaltransmitter 162 that transmits a drive identification signal. The driveidentification signal indicates to other mobile drive units 20 that theobject transmitting the drive identification signal is in fact a mobiledrive unit. Identification signal transmitter 162 may be capable oftransmitting infrared, ultraviolet, audio, visible light, radio, and/orother suitable signals that indicate to recipients that the transmittingdevice is a mobile drive unit 20.

Additionally, in particular embodiments, obstacle sensor 160 may also becapable of detecting state information transmitted by other mobile driveunits 20. For example, in particular embodiments, identification signaltransmitter 162 may be capable of including state information relatingto mobile drive unit 20 in the transmitted identification signal. Thisstate information may include, but is not limited to, the position,velocity, direction, and the braking capabilities of the transmittingmobile drive unit 20. In particular embodiments, mobile drive unit 20may use the state information transmitted by other mobile drive units toavoid collisions when operating in close proximity with those othermobile drive units. FIGS. 12A-12E illustrate an example of how thisprocess may be implemented in particular embodiments of inventory system10.

Control module 170 monitors and/or controls operation of drive module120 and docking actuator 130. Control module 170 may also receiveinformation from sensors such as position sensor 140 and holder sensor150 and adjust the operation of drive module 120, docking actuator 130,and/or other components of mobile drive unit 20 based on thisinformation. Additionally, in particular embodiments, mobile drive unit20 may be configured to communicate with a management device ofinventory system 10 and control module 170 may receive commandstransmitted to mobile drive unit 20 and communicate information back tothe management device utilizing appropriate communication components ofmobile drive unit 20. Control module 170 may include any appropriatehardware and/or software suitable to provide the describedfunctionality. In particular embodiments, control module 170 includes ageneral-purpose microprocessor programmed to provide the describedfunctionality. Additionally, control module 170 may include all orportions of docking actuator 120, drive module 130, position sensor 140,and/or holder sensor 150, and/or share components with any of theseelements of mobile drive unit 20.

Moreover, in particular embodiments, control module 170 may includehardware and software located in components that are physically distinctfrom the device that houses drive module 120, docking actuator 130,and/or the other components of mobile drive unit 20 described above. Forexample, in particular embodiments, each mobile drive unit 20 operatingin inventory system 10 may be associated with a software process(referred to here as a “drive agent”) operating on a server that is incommunication with the device that houses drive module 120, dockingactuator 130, and other appropriate components of mobile drive unit 20.This drive agent may be responsible for requesting and receiving tasks,requesting and receiving routes, transmitting state informationassociated with mobile drive unit 20, and/or otherwise interacting withmanagement module 15 and other components of inventory system 10 onbehalf of the device that physically houses drive module 120, dockingactuator 130, and the other appropriate components of mobile drive unit20. As a result, for the purposes of this description and the claimsthat follow, the term “mobile drive unit” includes software and/orhardware, such as agent processes, that provides the describedfunctionality on behalf of mobile drive unit 20 but that may be locatedin physically distinct devices from the drive module 120, dockingactuator 130, and/or the other components of mobile drive unit 20described above.

While FIGS. 3A and 3B illustrate a particular embodiment of mobile driveunit 20 containing certain components and configured to operate in aparticular manner, mobile drive unit 20 may represent any appropriatecomponent and/or collection of components configured to transport and/orfacilitate the transport of inventory holders 30. As another example,mobile drive unit 20 may represent part of an overhead crane system inwhich one or more crane assemblies are capable of moving within anetwork of wires or rails to a position suitable to dock with aparticular inventory holder 30. After docking with inventory holder 30,the crane assembly may then lift inventory holder 30 and move inventoryto another location for purposes of completing an assigned task.

Furthermore, in particular embodiments, mobile drive unit 20 mayrepresent all or a portion of inventory holder 30. Inventory holder 30may include motorized wheels or any other components suitable to allowinventory holder 30 to propel itself. As one specific example, a portionof inventory holder 30 may be responsive to magnetic fields. Inventorysystem 10 may be able to generate one or more controlled magnetic fieldscapable of propelling, maneuvering and/or otherwise controlling theposition of inventory holder 30 as a result of the responsive portion ofinventory holder 30. In such embodiments, mobile drive unit 20 mayrepresent the responsive portion of inventory holder 30 and/or thecomponents of inventory system 10 responsible for generating andcontrolling these magnetic fields. While this description providesseveral specific examples, mobile drive unit 20 may, in general,represent any appropriate component and/or collection of componentsconfigured to transport and/or facilitate the transport of inventoryholders 30.

FIG. 4 illustrates in greater detail the components of a particularembodiment of inventory holder 30. In particular, FIG. 4 illustrates thestructure and contents of one side of an example inventory holder 30. Ina particular embodiment, inventory holder 30 may comprise any number offaces with similar or different structure. As illustrated, inventoryholder 30 includes a frame 310, a plurality of legs 328, and dockingsurface 350.

Frame 310 holds inventory items 40. Frame 310 provides storage space forstoring inventory items 40 external or internal to frame 310. Thestorage space provided by frame 310 may be divided into a plurality ofinventory bins 320, each capable of holding inventory items 40.Inventory bins 320 may include any appropriate storage elements, such asbins, compartments, or hooks.

In a particular embodiment, frame 310 is composed of a plurality oftrays 322 stacked upon one another and attached to or stacked on a base318. In such an embodiment, inventory bins 320 may be formed by aplurality of adjustable dividers 324 that may be moved to resize one ormore inventory bins 320. In alternative embodiments, frame 310 mayrepresent a single inventory bin 320 that includes a single tray 322 andno adjustable dividers 324. Additionally, in particular embodiments,frame 310 may represent a load-bearing surface mounted on mobilityelement 330. Inventory items 40 may be stored on such an inventoryholder 30 by being placed on frame 310. In general, frame 310 mayinclude storage internal and/or external storage space divided into anyappropriate number of inventory bins 320 in any appropriate manner.

Additionally, in a particular embodiment, frame 310 may include aplurality of device openings 326 that allow mobile drive unit 20 toposition docking head 110 adjacent docking surface 350. The size, shape,and placement of device openings 326 may be determined based on thesize, the shape, and other characteristics of the particular embodimentof mobile drive unit 20 and/or inventory holder 30 utilized by inventorysystem 10. For example, in the illustrated embodiment, frame 310includes four legs 328 that form device openings 326 and allow mobiledrive unit 20 to position mobile drive unit 20 under frame 310 andadjacent to docking surface 350. The length of legs 328 may bedetermined based on a height of mobile drive unit 20.

Docking surface 350 comprises a portion of inventory holder 30 thatcouples to, abuts, and/or rests upon a portion of docking head 110, whenmobile drive unit 20 is docked to inventory holder 30. Additionally,docking surface 350 supports a portion or all of the weight of inventoryholder 30 while inventory holder 30 is docked with mobile drive unit 20.The composition, shape, and/or texture of docking surface 350 may bedesigned to facilitate maneuvering of inventory holder 30 by mobiledrive unit 20. For example, as noted above, in particular embodiments,docking surface 350 may comprise a high-friction portion. When mobiledrive unit 20 and inventory holder 30 are docked, frictional forcesinduced between docking head 110 and this high-friction portion mayallow mobile drive unit 20 to maneuver inventory holder 30.Additionally, in particular embodiments, docking surface 350 may includeappropriate components suitable to receive a portion of docking head110, couple inventory holder 30 to mobile drive unit 20, and/orfacilitate control of inventory holder 30 by mobile drive unit 20.

Holder identifier 360 marks a predetermined portion of inventory holder30 and mobile drive unit 20 may use holder identifier 360 to align withinventory holder 30 during docking and/or to determine the location ofinventory holder 30. More specifically, in particular embodiments,mobile drive unit 20 may be equipped with components, such as holdersensor 150, that can detect holder identifier 360 and determine itslocation relative to mobile drive unit 20. As a result, mobile driveunit 20 may be able to determine the location of inventory holder 30 asa whole. For example, in particular embodiments, holder identifier 360may represent a reflective marker that is positioned at a predeterminedlocation on inventory holder 30 and that holder sensor 150 can opticallydetect using an appropriately-configured camera.

FIGS. 5 and 6 illustrate a technique for planning and directing themovement of mobile drive units 20 within workspace 70 while the mobiledrive units 20 complete assigned tasks. More specifically, FIG. 5illustrates an example of how a mobile drive unit 20 may request, frommanagement module 15, a path to a destination associated with anassigned task and then interact with management module 15 to allowmobile drive unit 20 to successfully traverse the path. FIG. 6 is aflowchart detailing example operation of a particular embodiment ofmobile drive unit 20 in moving to a designated destination according tothe techniques illustrated by FIG. 5.

FIG. 5 illustrates an example showing routing and reservation techniquesthat may be utilized in particular embodiments of inventory system 10.In general, FIG. 5 illustrates an example in which mobile drive unit 20receives an assigned task 18 from management module 15 that instructsmobile drive unit 20 to retrieve inventory holder 30 a from a storagecell where inventory holder 30 a is currently located. Mobile drive unit20 then requests a path to the location of inventory holder 30 a andfollows the received path to the relevant location.

In the illustrated embodiment of inventory system 10, workspace 70 isassociated with a grid 12 comprising a plurality of cells 14, and mobiledrive units 20 are configured to move within workspace 70 by navigatingfrom the center of one cell 14 to the center of another. Nonetheless, inalternative embodiments, mobile drive units 20 may be configured tonavigate grid 12 in any appropriate manner and starting points,destinations, and any intermediate points on the path traversed bymobile drive unit 20 may or may not represent the center point of a cell14 or any other portion of grid 12. Furthermore, although FIG. 5illustrates a grid-based embodiment of inventory system 10, alternativeembodiments of inventory system 10 may utilize a gridless workspacehaving an arbitrary shape and structure.

As shown in FIG. 5, the routing process begins with management module 15transmitting a task assignment 18 to mobile drive unit 20. Taskassignment 18 identifies one or more destinations associated with acorresponding task. Task assignment 18 may identify the relevantdestinations directly or by reference to the known location of specificcomponents (e.g., a particular inventory holder 30 or inventory station50) or a particular portion of workspace 70. Task assignment 18 may alsoinclude any additional information suitable for mobile drive unit 20 touse in completing the assigned task.

Upon receiving task assignment 18, mobile drive unit 20 requests a pathto the location identified by the task assignment 18 or, if taskassignment 18 identifies multiple locations, to the first locationidentified by task assignment 18. In the illustrated embodiment, mobiledrive unit 20 requests a path by transmitting a route request 22 toroute planning module 94. In particular embodiments, route request 22may include one or more destination locations and the current locationof mobile drive unit 20 or the anticipated location of mobile drive unit20 when it completes its current segment 17. In alternative embodiments,management module 15 may independently monitor the location or assignedtask of each mobile drive unit 20 and, consequently, one or more ofthese locations may be omitted from route request 22.

When route planning module 94 receives route request 22, route planningmodule 94 generates a path 16 for the requesting mobile drive unit 20 touse in moving from its current location to the requested destination. Asnoted above, route planning module 94 may use any suitable techniques togenerate, select, or determine an appropriate path 16 for the requestingmobile drive unit 20. Route planning module 94 may then communicateinformation identifying path 16 to the requesting mobile drive unit 20as part of a route response 24. For example, route planning module 94may communicate information specifying certain points along path 16,specifying directions and distances to move, specifying known pathsegments to use in moving to the requested destination, specifying otherequipment (for example, a lift, conveyor, or truck) or features of theworkspace (such as a ramp or tunnel) to be utilized, and/or indicating,in any other appropriate manner, the portion of workspace 70 mobiledrive unit 20 should traverse in moving between its current location andthe requested destination. In particular embodiments, route planningmodule 94 communicates path 16 to mobile drive unit 20 as part of routeresponse 24.

After route planning module 94 transmits information identifying one ormore paths 16, this information is received by mobile drive unit 20. Inparticular embodiments, mobile drive unit 20 may then store thisinformation for subsequent use in navigating to the destinationlocation. Mobile drive unit 20 then attempts to reserve a segment 17 orother suitable portion of path 16. Mobile drive unit 20 may reserve asegment 17 of path 16 by taking any appropriate steps, based on theconfiguration of inventory system 10, to ensure that no other mobiledrive unit 20, or other type of device capable of moving withinworkspace 70, is or will be traversing the reserved segment 17,positioned on the reserved segment 17, and/or otherwise impedingmovement along the reserved segment 17 while the relevant mobile driveunit 20 has that segment 17 reserved.

In particular embodiments, route planning module 94 may, in response toa particular route request 22, generate multiple paths to a particulardestination. Moreover, management module 15 may then transmit all of thegenerated paths 16 to the requesting mobile drive unit 20. Additionally,route planning module 94 or mobile drive unit 20 may assign a priorityto each of the generated paths 16. As a result, in such embodiments, therequesting mobile drive unit 20 may be capable of storing the multiplepaths 16 generated by route planning module 94 and then attempting toreserve segments 17 of the highest priority path 16. If the attemptedreservation is denied, the requesting mobile drive unit 20 may thenattempt to request a segment 17 from the next highest priority path 16.The requesting mobile drive unit 20 may then proceed to request segments17 from each of the received paths 16 in order of priority until therequesting mobile drive unit 20 successfully reserves segments 17 fromone of the received paths 16.

Furthermore, in particular embodiments or under certain conditions,multiple mobile drive units 20 may be allowed to utilize a particularsegment 17 simultaneously. In such embodiments, mobile drive unit 20 mayreserve a segment 17 by taking any appropriate steps to ensure that onlymobile drive units 20 that satisfy particular conditions may use thereserved segment at the same time. As one example, in particularembodiments, segment reservation module 96 may reserve a particularsegment by taking appropriate steps to ensure that only mobile driveunits 20 moving in the same direction as that mobile drive unit 20 mayreserve the relevant segment 17. As another example, in particularembodiments, inventory system 10 may be configured to allow apredetermined maximum number or concentration of mobile drive units 20to use a given segment 17 and mobile drive unit 20 may reserve a givensegment 17 by requesting a reservation for that segment 17. Managementmodule 15 may then conditionally grant the reservation based on whetherthe current number or density of mobile drive units 20 utilizing therequested segment 17 is less than the predetermined maximum.

In the illustrated embodiment, mobile drive unit 20 reserves segment 17by transmitting a reservation request 26 to segment reservation module96. Reservation request 26 identifies the segment 17 that mobile driveunit 20 is attempting to reserve. Reservation request 26 may identifythe relevant segment 17 in any manner appropriate based on theconfiguration and capabilities of mobile drive unit 20 and segmentreservation module 96. For example, in particular embodiments,reservation request 26 identifies the relevant segment 17 by identifyingthe starting and ending coordinates of that segment 17, by specifying adirection and distance from the current location of mobile drive unit20, or by including any other suitable information from which therequested segment 17 can be identified, either independently or based onother information maintained by segment reservation module 96 duringoperation.

Segment reservation module 96 receives the reservation request 26 andextracts information identifying the requested segment 17 fromreservation request 26. Segment reservation module 96 then determineswhether or not the requesting mobile drive unit 20 can reserve therequested segment 17. In particular embodiments, segment reservationmodule 96 determines based solely on whether another mobile drive unit20 currently has the requested segment 17 reserved. In alternativeembodiments, however, segment reservation module 96 may determine basedboth on whether another mobile drive unit 20 currently has the requestedsegment 17 reserved and on a priority level associated with therequesting mobile drive unit 20 or a task the mobile drive unit 20 iscurrently completing whether the requesting mobile drive unit 20 canreserve the requested segment 17. Consequently, segment reservationmodule 96 may refuse use of certain segments 17 (or segments 17exceeding a certain size) to mobile drive units 20 having aninsufficient priority level. In general, however, segment reservationmodule 96 may use any appropriate considerations to determine whetherthe received reservation request 26 can be satisfied.

Additionally, in particular embodiments, segment reservation module 96may be configured to compensate for potential uncertainties in thelocation of mobile drive unit 20. In particular, segment reservationmodule 96 may attempt to reserve a modified segment that includes, butis larger than, the requested segment 17. As a result, if the actuallocation of the requesting mobile drive unit 20 differs, by less thansome predetermined amount, from that calculated by mobile drive unit 20and/or management module 15, collisions may still be prevented as aresult of the larger reservation secured by segment reservation module96. Segment reservation module 96 may be configured to always modifyreservation requests 26 in this manner, to modify reservation requests26 when management module 15 determines the actual location of therequesting mobile drive unit 20 differs from the calculated location, orto modify reservation requests 26 at any other appropriate times.

Furthermore, in particular embodiments of inventory system 10, mobiledrive units 20 may attempt to make and/or resource scheduling module 92may grant reservations of different types depending on the manner inwhich requesting mobile drive units 20 intend to use the requestedsegment 17. Moreover, resource scheduling module 92 may follow differentpolicies for granting or denying each of these different types ofreservations. For example, in particular embodiments, mobile drive units20 may be configured to request a segment 17 that includes one or morecells 14 adjacent to the cells 14 through which path 16 runs.Consequently, when a requesting mobile drive unit 20 plans to rotateinventory holder 30 as part of its movement in completing a particularsegment 16, the requesting mobile drive unit 20 may attempt to placerotation reservations on the cells 14 adjacent to the cell 14 in whichmobile drive unit 20 intends to perform the rotation. Depending on thesize of inventory holders 30 relative to the cells 14 utilized in therelevant workspace 70, the requesting mobile drive unit 20 may not needto use the entirety of each neighboring cell 14 to rotate. As a result,segment reservation module 96 may allow other mobile drive units 20 toalso place reservation requests on a particular neighboring cell 14 atthe same time the first requesting mobile drive unit 20 has reservedthat particular cell 14. More specifically, in particular embodiments,resource scheduling module 92 may allow other mobile drive units 20 toreserve the neighboring cell 14 for purposes of encroaching into thatcell 14 while rotating inventory holders 30 in other cells 14 thatborder the neighboring cell 14. This may reduce the number of delaysmobile drive units 20 face when attempting to reserve a sufficientlylarge portion of workspace 70 to rotate inventory holders 30.

If segment reservation module 96 determines that the requesting mobiledrive unit 20 cannot reserve the requested segment 17, segmentreservation module 96 may notify the requesting mobile drive unit 20that it did not successfully reserve the requested segment 17. Forexample, in the illustrated embodiment, segment reservation module 96transmits a reservation response 28 that indicates the reservation wasunsuccessful. Alternatively, in particular embodiments, segmentreservation module 96 does not notify the requesting mobile drive unit20 of the failed reservation, and the requesting mobile drive unit 20 isconfigured to determine the reservation was unsuccessful if therequesting mobile drive unit 20 does not receive an affirmative responsewithin a predetermined period of time.

Additionally, in particular embodiments, segment reservation module 96may be configured to take some remedial action if segment reservationmodule 96 is unable to satisfy a particular reservation request 26. Forexample, in particular embodiments, segment reservation module 96 mayqueue unsatisfied reservation requests 26 and attempt to satisfy themonce any currently pending reservation for the requested segment 17 isterminated. Alternatively, however, segment reservation module 96 may beconfigured to discard unsatisfied reservation requests 26 after a singleattempt to satisfy them, after a predetermined number of failedattempts, or after unsuccessfully attempting to satisfy such requestsfor a predetermined amount of time. The requesting mobile drive unit 20may then be expected to transmit another reservation request 26 later ifit is still attempting to reserve the requested segment 17. In addition,segment reservation module 96 may be configured to attempt reserving aportion of the requested segment 17 or a modified version of therequested segment 17 if the segment reservation module 96 is unable tosuccessfully reserve the originally requested segment 17 for therequesting mobile drive unit 20. More generally, however, depending onthe configuration of inventory system 10, segment reservation module 96may be configured to take any appropriate remedial action or,alternatively, to take no remedial action at all, if segment reservationmodule 96 is unable to satisfy a particular reservation request 26.

Similarly, depending on the configuration of mobile drive unit 20,mobile drive unit 20 may execute any appropriate remedial action inresponse to determining that segment reservation module 96 has notsatisfied the reservation. In particular embodiments, mobile drive unit20 may wait a predetermined amount of time and attempt to reserve thesame segment 17 again. In alternative embodiments, mobile drive unit 20may be configured to request a new path 16 from route planning module94, if mobile drive unit 20 is unsuccessful in reserving the requestedsegment 17 or if mobile drive unit 20 is unsuccessful after apredetermined number of attempts. Additionally, in particularembodiments, mobile drive units 20 may be able to adjust the size of thesegments 17 mobile drive units 20 request. As a result, the requestingmobile drive unit 20 may, in response to determining that the attemptedreservation was unsuccessful, attempt to reserve a smaller portion ofthe same requested segment 17. In such embodiments, the requestingmobile drive unit 20 may then request or automatically receiveincremental portions of the original requested segment 17 as therequesting mobile drive unit 20 moves and/or the remaining portionsbecome free. More generally, however, mobile drive unit 20 may respondin any suitable manner to the failed reservation attempt.

If, instead, segment reservation module 96 determines that the receivedreservation request 26 can be satisfied, segment reservation module 96reserves the requested segment 17 for the requesting mobile drive unit20. As part of reserving the requested segment, segment reservationmodule 96 stores information indicating the reserved state of therelevant segment 17 and takes any additional steps appropriate to ensurethat the requesting mobile drive unit 20 may use the requested segment17 until the reservation is terminated. Segment reservation module 96also notifies the requesting mobile drive unit 20 that it hassuccessfully reserved the requested segment 17. For example, in theillustrated embodiment, segment reservation module 96 transmits anacknowledgement, such as reservation response 28, that indicates to therequesting mobile drive unit 20 that the reservation was successful.When the requesting mobile drive unit 20 receives the reservationresponse 28 indicating that the attempted reservation was successful,the requesting mobile drive unit 20 begins moving along the reservedsegment 17.

Returning to the example illustrated in FIG. 5, when mobile drive unit20 a receives reservation response 28 indicating that mobile drive unit20 a has successfully reserved segment 17 a, mobile drive unit 20 beginsmoving along segment 17 a. This is illustrated is in FIG. 5 by thedotted-line silhouette of mobile drive unit 20. At some point afterbeginning movement along segment 17 a, mobile drive unit 20 a attemptsto reserve the next segment of the path that mobile drive unit 20 areceived from route planning module 94, i.e., segment 17 b. Inparticular embodiments, mobile drive unit 20 a may wait until mobiledrive unit 20 a reaches the end of the reserved segment (i.e., whenmobile drive unit 20 a reaches the second silhouette) and then requestthe next segment 17.

Alternatively, mobile drive unit 20 a may attempt to reserve segment 17b before completing segment 17 a. In particular embodiments, mobiledrive unit 20 a may request segment 17 b at an appropriate point whilemoving across segment 17 a. As one example, mobile drive unit 20 a mayrequest segment 17 b after completing a predetermined proportion ofsegment 17 a (e.g., after completing 75% of segment 17 a). As anotherexample, mobile drive unit 20 may request segment 17 b when only apredetermined amount of segment 17 a is left to be completed (e.g., oncemobile drive unit 20 a has completed all but half a cell's width ofsegment 17 a). More generally, however, particular embodiments of mobiledrive unit 20, or any appropriate component of inventory system 10responsible for reserving segments 17 on behalf of mobile drive unit 20,may be configured to reserve the next segment in the current path at anysuitable time while mobile drive unit 20 is moving along itscurrently-reserved segment 17. The remainder of this description assumesthat mobile drive unit 20 is configured to attempt reservation of a newsegment 17 before completing its current segment 17.

Additionally, as discussed above with respect to FIGS. 3A and 3B,particular embodiments of mobile drive unit 20 a may include one or moresensors capable of detecting certain types of obstacles, obstructions,or other impediments to the movement of mobile drive unit 20. Inresponse to detecting an obstacle, mobile drive unit 20 may beconfigured to stop and/or take any appropriate measures to complete theassigned task. As one example, mobile drive unit 20 may stop moving andperiodically poll the relevant sensor to determine whether the obstaclehas been removed. As another example, mobile drive unit 20 a may requesta new path upon detecting an obstacle located on or near a segment 17 ofits current path 16. As yet another example, mobile drive unit 20 maynotify management module 15 or a human operator of inventory system 10to initiate appropriate actions to have the obstacle removed. Inparticular embodiments, mobile drive unit 20 a may be configured tooverride its obstacle detection capabilities to support certain types ofspecial navigation techniques. An example of these techniques isdiscussed in greater detail below with respect to FIGS. 12A-12E, 13, and14.

In particular embodiments, as mobile drive unit 20 a exits a particularcell 14 of segment 17 a, mobile drive unit 20 a may release itsreservation with respect to that cell 14. Alternatively, in particularembodiments, mobile drive unit 20 a may wait until reaching the end ofsegment 17 a (i.e., when mobile drive unit 20 a arrives at the secondsilhouette), and then terminate its reservation of all cells 14 insegment 17 a. Mobile drive unit 20 a may release its reservation of allor a portion of segment 17 a by transmitting a reservation terminationmessage (not shown) to segment reservation module 96 or by taking anyother appropriate steps to relinquish its use of segment 17 a.Alternatively, in particular embodiments, mobile drive unit 20 a may notbe configured to take any affirmative steps to terminate thereservation. Instead, segment reservation module 96 may itself detectthat mobile drive unit 20 a has completed segment 17 a and terminate thereservation in response or segment reservation module 96 may time-outthe reservation if mobile drive unit 20 a does not renew the reservationwithin a predetermined time period. More generally, segment reservationmodule 96 may monitor any particular aspect of the operation of mobiledrive unit 20 a including, for example, its location, speed, lastrenewal request, and/or any other appropriate aspect of the state ofmobile drive unit 20 a, and terminate the reservation at any appropriatetime based on the state of mobile drive unit 20 a.

If mobile drive unit 20 a has successfully reserved segment 17 b by thetime mobile drive unit 20 a reaches the end of segment 17 a, mobiledrive unit 20 a may begin moving along segment 17 b. If mobile driveunit 20 a has not successfully reserved segment 17 b by the time mobiledrive unit 20 a reaches the end of segment 17 a, mobile drive unit 20 amay stop at the intersection of segment 17 a and segment 17 b and takeappropriate steps based on the configuration of mobile drive unit 20 a.For example, as noted above, mobile drive unit 20 a may repeatedlyattempt to reserve segment 17 b until successful, make a predeterminednumber of reservation attempts and then request a new path 16, or takeany other steps to continue its movement towards the destinationlocation.

Once mobile drive unit 20 a successfully reserves segment 17 b, mobiledrive unit 20 a traverses segment 17 b in a similar fashion. At anappropriate point during the completion of segment 17 b, mobile driveunit 20 a attempts to reserve segment 17 c and repeats the aboveprocess. Mobile drive unit 20 a continues reserving and traversingsegments (as suggested by the dotted-line silhouettes) until mobiledrive unit 20 a reaches the destination location. Mobile drive unit 20 amay then take any actions appropriate to complete the assigned task. Forexample, in FIG. 5, completion of the assigned task may include mobiledrive unit 20 a docking with a particular inventory holder 30 located atthe destination location. If the currently-assigned task includesmultiple destinations, mobile drive unit 20 a may request a path 16 tothe next step by transmitting a new route request 22 to route planningmodule 94 and repeating the above process with respect to the nextdestination. If the task assignment 18 that mobile drive unit 20 areceived does not specify any additional locations, mobile drive unit 20a may request or be given another assigned task from resource schedulingmodule 92 or otherwise notify management module 15 that mobile driveunit 20 a is available for new assignments.

Although the illustrated example, utilizes only straight segments 17,particular embodiments of inventory system 10 may be configured togenerate paths that include segments covering turns, curves, and othernon-linear portions. Additionally, although in the illustrated examplesegments 17 extend without limit between turns in path 16, particularembodiments of inventory system 10 may be configured to generate paths16 that have an upper limit on segment length or to allow only up to amaximum segment length to be reserved with a single reservation. As aresult, a relatively long straight segment, such as segment 17 c, may inreality represent a series of smaller, connected segments 17 running inthe same direction.

Additionally, although mobile drive unit 20 a relies on a single path inthe illustrated example, mobile drive units 20 may, in particularembodiments, be configured to request new paths 16 to a particularlocation while in the process of completing a previously-requested path16 to the same location. As noted above, mobile drive units 20 may beconfigured to request a new path 16 if they are unsuccessful inreserving a particular segment 17 in the current path 16. Moregenerally, however, mobile drive units 20 may be configured to request anew path 16 to a particular destination at any appropriate time whilecompleting an existing path 16 to the same destination. For example, aparticular embodiment of mobile drive unit 20 may request a new path 16a predetermined amount of time after requesting the original path, aftercompleting each segment 17, or at any other suitable time. In suchembodiments, mobile drive unit 20 may transmit the originally receivedpath 16 back to route planning module 94 to be used as a starting pointfor determining any improved paths 16 to the same destination.

Moreover, management module 15 may be capable of pushing new paths 16 toa mobile drive unit 20 while that mobile drive unit 20 is in the processof completing a previously-received path 16. As one example, inparticular embodiments, management module 15 may be configured to managecongestion by transmitting new paths 16 to mobile drive units 20 thatare located in or near congested areas or that are traveling on pathsthat will traverse or pass near congested areas. As another example,management module 15 may be configured to improve the operationalefficiency of inventory system 10 by transmitting new paths 16 to mobiledrive units 20 that are optimized based on the attributes of inventoryholders 30 or inventory stations 50 associated with the relevant mobiledrive units 20 or the tasks they are completing. In general, eithermobile drive unit 20 or route planning module 94 may determine thatmobile drive unit 20 should receive a new path 16 based on changes inany appropriate condition, circumstance, property, or state of inventorysystem 10 or any individual components of inventory system 10.

In addition, although the illustrated example, describes an exampleembodiment in which route planning module 94 transmits the entirety ofpath 16 to mobile drive unit 20 a at one time, particular embodiments ofroute planning module 94 may be configured to transmit path 16 inportions. For example, in a particular embodiment, route planning module94 may be configured to transmit path 16 to the requesting mobile driveunit 20 one segment 17 at a time. After traversing a particular segment17, the requesting mobile drive unit 20 may then request another segment17 of the path 16. At that point, route planning module 94 maydetermine, based on changes in conditions within workspace 70 and/or anyother appropriate considerations, whether to provide the next segment 17in the original path 16 or to generate a new path 16 to the destinationof the requesting mobile drive unit 20. Route planning module 94 thencommunicates another segment 17, either from the original path 16 or anew path 16, to the requesting mobile drive unit 20. This process maycontinue until the requesting mobile drive unit 20 reaches itsdestination.

Furthermore, while the illustrated example focuses on an embodiment ofinventory system 10 in which mobile drive units 20 actively requestreservation of particular segments 17 on their own behalf, inalternative embodiments management module 15 or other suitablecomponents of inventory system 10 may be responsible for initiatingreservations, either explicitly or implicitly. As one example, inparticular embodiments, management module 15 may monitor the locationand current path of mobile drive units 20 and may reserve appropriatesegments 17 on behalf of mobile drive units 20 at appropriate timesduring the movement of mobile drive units 20. As another example,particular embodiments of inventory system 10 may include signalingdevices, such as traffic signals, that mange the flow of traffic withinworkspace 70. As a result, management module 15 or other components thatcontrol the signaling devices may implicitly reserve a particularsegment 17 for a mobile drive unit 20 by signaling to other mobile driveunits 20 that they are not permitted to use the relevant segment 17 at aparticular time.

Consequently, inventory system 10 supports a number of techniques thatprovide for efficient routing, navigation, and management of mobiledrive units 20 moving within workspace 70. Because inventory system 10supports techniques for resolving conflicting requests for a particularsegment 17 by two different mobile drive units 20 management module 15may also help reduce or eliminate collisions between mobile drive units20 simultaneously completing tasks. As a result, the describedtechniques may provide one or more operational benefits.

FIG. 6 is a flow chart illustrating the operation of a particularembodiment of mobile drive unit 20 in traversing a path 16 to adesignated location. More specifically, FIG. 6 illustrates the processby which mobile drive unit 20, in particular embodiments of inventorysystem 10, requests a path to a particular destination and iterativelyreserves and traverses the various segments 17 of that path 16. Any ofthe steps illustrated in FIG. 6 may be combined, modified, or deletedwhere appropriate, and additional steps may also be added to those shownin the flowchart. Moreover, the described steps may be performed in anysuitable order without departing from the scope of the invention.

The example operation begins, at step 602, with mobile drive unit 20receiving a task assignment 18 from resource scheduling module 92. Taskassignment 18 identifies one or more locations associated with a taskassigned to mobile drive unit 20. In response to receiving taskassignment 18, mobile drive unit 20 requests, from route planning module94, a path to one of the destinations identified in task assignment 18.In particular embodiments, mobile drive unit 20 requests the path bytransmitting a route request 22 to route planning module 94 at step 604.Route request 22 identifies a destination location and the currentlocation of mobile drive unit 20.

At step 606, route planning module 94 generates, selects, or identifiesa path 16 from the current location of mobile drive unit 20 to thedestination location. Route planning module 94 then transmits path 16 tomobile drive unit 20. In particular embodiments, route planning module94 transmits path 16 to mobile drive unit 20 by transmitting a routeresponse 24 to mobile drive unit 20, at step 608, that identifies path16 in an appropriate manner based on the capabilities of mobile driveunit 20. In particular embodiments, path 16 includes multiple segments17, including at least an initial segment 17 and one or more additionalsegments 17. The initial segment 17 is associated with a section ofworkspace 70 adjacent to the current location of mobile drive unit 20when mobile drive unit 20 requests the path, and at least one of theadditional segments 17 is associated with a section of workspace 70adjacent to the destination. Path 16 may include any number ofadditional segments 17.

After receiving the path from route planning module 94, mobile driveunit 20 attempts to reserve the initial segment 17 of the received path16. In particular embodiments, mobile drive unit 20 attempts to reservethe initial segment 17 by transmitting a reservation request 26 tosegment reservation module 96 at step 610. Reservation request 26identifies the requested segment 17.

Upon receiving reservation request 26, segment reservation module 96attempts to reserve the requested segment 17 for mobile drive unit 20 at612. In particular embodiments, segment reservation module 96 may modifythe requested segment 17 to account for potential uncertainties orerrors in the calculated position of mobile drive unit 20. As a result,in particular embodiments, segment reservation module 96 may reserve aportion of workspace 70 other than the segment specified by the receivedreservation request 26. For example, segment reservation module 96 may,under appropriate circumstances, expand, translate, and/or otherwisemodify the requested segment to create a modified segment more suitablefor use by the requesting mobile drive unit 20. In particularembodiments, segment reservation module 96 may be configured to modifythe requested segment based on an error margin utilized by inventorysystem 10. Segment reservation module 96 may, as a result, attempt toreserve a portion of workspace 70 that is expanded, shifted, orotherwise modified from the reserved segment 17 in an amount determinedbased on the error margin. As a specific example, in particularembodiments that utilize a grid-based workspace 70 that includes aplurality of cells 14, segment reservation module 96 may attempt toreserve a segment 17 that includes one or more cells 14, beyond thatincluded in the requested segment 17, that extend in the direction thatthe requesting mobile drive unit 20 is currently traveling. As anotherexample, in particular embodiments, segment reservation module 96 mayattempt to reserve a segment that has been shifted a particular numberof cells in a specified direction.

Segment reservation module 96 may then notify mobile drive unit 20 ofwhether or not mobile drive unit 20 has successfully reserved a segment17 for mobile drive unit 20. Alternatively, segment reservation module96 may notify mobile drive unit 20 only of successful reservationattempts. In particular embodiments, segment reservation module 96notifies mobile drive unit 20 by transmitting a reservation response 28to mobile drive unit 20 at step 614.

At step 616, mobile drive unit 20 determines whether mobile drive unit20 has successfully reserved the initial segment 17. If mobile driveunit 20 was not successful in reserving the initial segment 17, mobiledrive unit 20 may take appropriate steps to continue working towardcompletion of the assigned task. For example, in the illustratedembodiment, mobile drive unit 20 waits a predetermined amount of timeand attempts to reserve the initial segment again at step 618. Moreover,in the illustrated embodiment, mobile drive unit 20 determines at step620 if the second attempt is successful. If the second attempt issuccessful, operation continues at step 622. If the second attempt isnot successful, operation returns to 604 with mobile drive unit 20requesting a new path 16.

Once mobile drive unit 20 is able to successfully reserve the initialsegment 17, mobile drive unit 20 begins moving away from its originallocation along the initial segment of the path at step 622. At step 624,mobile drive unit 20 determines that there is less than a predeterminedportion of the initial segment 17 left to complete. As a result, mobiledrive unit 20 determines, at step 626, whether any additional segments17 remain to be completed in the current path 16.

If segments 17 remain to be completed in the current path 16, mobiledrive unit 20 attempts to reserve the next segment 17, returning to step610. If mobile drive unit 20 successfully reserves the next segmentoperation continues with mobile drive unit 20 moving along the nextsegment 17. If mobile drive unit is not successful in reserving the nextsegment 17, operation continues through to step 622. If mobile driveunit 20 reaches the end of the initial segment 17 before successfullyreserving the next segment, mobile drive unit 20 may pause its movementat the end of the initial segment and remain stationary until mobiledrive unit 20 successfully reserves the next segment or obtains analternative path.

If no segments 17 remain to be completed in the current path, mobiledrive unit 20 determines whether any destinations remain to be visitedin the current task assignment 18 at step 628. If so, operation returnsto step 604. If not, mobile drive unit 20 may notify resource schedulingmodule 92 that mobile drive unit 20 has completed its current task atstep 630. Operation with respect to completing the current task may thenend as shown in FIG. 6.

FIGS. 7 and 8 illustrate a technique for planning paths based on thecurrent state of a requesting mobile drive unit 20. More specifically,FIG. 7 illustrates an example of how such techniques might beimplemented in a particular inventory system 10, and FIG. 8 is aflowchart detailing example operation of management module 15 inimplementing a particular embodiment of these techniques. As one exampleof how such a technique might be used in inventory system 10, particularembodiments of inventory system 10 may allow mobile drive units 20 thatare not docked to an inventory holder 30 to move through spacescurrently occupied by stored inventory holders 30, but mobile driveunits 20 that are docked with inventory holders 30 may not be capable ofdoing so. As a result, when undocked, mobile drive units 20 may be ableto “tunnel” through cells 14 having inventory holders 30, therebyallowing for more effective use of system resources.

FIG. 7 illustrates techniques that may be used by management module 15in generating appropriate paths 16 for mobile drive units 20. Morespecifically, in particular embodiments, when mobile drive unit 20requests a path 16, route planning module 94, management module 15 ingeneral, or other appropriate components of inventory system 10determine a state of the requesting mobile drive unit 20. As used inthis description and the claims that follow, “state” may refer totransitional, temporary conditions, such as a current task assignment,that are associated with the requesting mobile drive unit 20 as well aspermanent characteristics and properties, such as height and width,associated with the requesting mobile drive unit 20.

Route planning module 94 then generates, selects, or identifies a pathbased in part on the state of the requesting mobile drive unit 20. Morespecifically, the state of mobile drive unit 20 may dictate the cellsthrough which mobile drive unit 20 can travel, and route planning module94 may produce a path 16 that utilizes appropriate cells 14. Toillustrate, FIG. 7 shows an example of two alternative paths 16, paths16 a and 16 b, that might be generated by route planning module 94 basedon a particular aspect of the state of the requesting mobile drive unit20 b. Specifically, FIG. 7 illustrates two paths 16 that may begenerated based on whether or not mobile drive unit 20 b is currentlydocked with an inventory holder 30.

To begin the example, mobile drive unit 20 b receives a task assignment18 as discussed above with respect to FIG. 5. Task assignment 18identifies a destination associated with a corresponding task assignedto mobile drive unit 20 b. In response to task assignment 18, mobiledrive unit 20 b requests path 16 from route planning module 94. In theexample, mobile drive unit 20 b requests path 16 by transmitting routerequest 22, which identifies the relevant destination location, herecell 14 b.

In response to route request 22, route planning module 94 generates apath 16 to the destination location by identifying, selecting and/orotherwise generating an appropriate path 16. In generating path 16,route planning module 94 considers a particular aspect of the state ofmobile drive unit 20 b, here its docking status. Based on the relevantaspect of the requesting mobile drive unit's state, route planningmodule 94 may determine that the requesting mobile drive unit 20 b isprohibited from moving through particular cells 14, from traversingparticular paths 16, and/or from utilizing particular equipment (e.g., adrive lift) within workspace 70, and/or that the state of mobile driveunit 20 b places some other form of restriction on the path 16 thatroute planning module 94 can properly generate for mobile drive unit 20b.

In particular embodiments, the requesting mobile drive unit 20 mayitself indicate the relevant state information to route planning module94. For example, in the illustrated embodiment, mobile drive unit 20 bmay indicate its docking status in route request 22. In alternativeembodiments, route planning module 94 may monitor one or more mobiledrive units 20 operating in workspace 70 and may maintain the relevantstate information as part of its normal operation. Additionally, inparticular embodiments, route planning module 94 may instead retrievethe relevant state information from other components of inventory system10 when a particular mobile drive unit 20 requests a path 16. Forexample, in particular embodiments, when route planning module 94receives a route request 22 from a particular mobile drive unit 20,route planning module 94 may communicate with resource scheduling module92 to determine whether the requesting mobile drive unit 20 is currentlyassigned a task.

In the illustrated example, it is assumed that mobile drive units 20that are currently docked with an inventory holder 30 are not allowed tomove through cells 14 of workspace 70 designated for the storage ofinventory holders 30 (referred to as storage cells 64). Consequently, ifmobile drive unit 20 b is currently docked to an inventory holder 30,route planning module 94 may generate a path for mobile drive unit 20that circumvents all designated storage cells, such as the path shown inFIG. 7 as path 16 a. On the other hand, if mobile drive unit 20 is notcurrently docked to an inventory holder 30, route planning module 94 maygenerate a path that includes designated storage cells 64, such as thepath shown in FIG. 7 as path 16 b.

Once route planning module 94 has generated the appropriate path 16,route planning module 94 communicates path 16 to the requesting mobiledrive unit 20. In the illustrated embodiment, route planning module 94transmits a route response 24 to the mobile drive unit 20 b thatidentifies path 16. Mobile drive unit 20 b then completes the receivedpath 16 as discussed above.

By considering the state of the requesting mobile drive unit 20 whengenerating path 16, route planning module 94 may make more intelligentdecisions regarding paths 16 that route planning module 94 generates forthat mobile drive unit 20. In particular embodiments, route planningmodule 94 may consider the state of a requesting mobile drive unit 20 toallow route planning module 94 to selectively use cells, paths, orequipment that might be prohibited for use by mobile drive units 20 of acertain state. Similarly, in particular embodiments, route planningmodule 94 may consider the state of a requesting mobile drive unit 20 tolimit the use of particular cells, paths, or equipment by mobile driveunits 20 of a particular state so that they can be available for use bymobile drive units 20 having states preferable for using the relevantcell, path, or equipment.

As one example, route planning module 94 may, as already discussed,consider the docking status of the requesting mobile drive unit 20 whengenerating the path. Similarly, in particular embodiments (for example,embodiments in which mobile drive units 20 do not actually dock withinventory holders 30 they transport), route planning module 94 mayalternatively consider whether the requesting mobile drive unit 20 iscarrying a load when generating the path. As a result, route planningmodule 94 may be able to selectively use a cell 14 that might otherwisebe prohibited for use in routing because docked or loaded mobile driveunits 20 cannot traverse the cell 14 in question due to the presence ofa stored inventory holder 30, the position of overhanging stairs, orother physical limitations that prevent a docked or loaded mobile driveunit 20 from being able to cross cell 14. Consequently, cells 14 thatmodule 15 might utilize such techniques to select a destination formobile drive units 20 based on their capability to complete tasks.Additionally, FIG. 11 is a flowchart illustrating example operation ofmanagement module 15 in a particular implementation of these techniques.As one example of how such a technique might be used in inventory system10, in particular embodiments of inventory system 10, mobile drive units20 and inventory holders 30 may be sized and shaped to allow an undockedmobile drive unit 20 and an inventory holder 30 to share the sameportion of workspace 70, such as storage cells 64. As a result,management module 15 may instruct mobile drive units 20 that are notcurrently engaged in completing any assigned tasks to park in a spacecurrently storing an inventory holder 30. This may reduce thepossibility of an idle mobile drive unit 20 becoming an obstacle inworkspace 70 and free more room for traffic. Additionally, thesetechniques may result in idle mobile drive units 20 being directed to alocation selected to best situate the relevant mobile drive unit 20 forresponding to its next assignment.

The example illustrated by FIG. 9 begins with resource scheduling module92 determining a state of mobile drive unit 20 c. In particular, in thisexample, resource scheduling module 92 determines an assignment state ofmobile drive unit 20 c. The assignment state may relate to whether therelevant mobile drive unit 20 is currently assigned one or more tasks,is actively engaged in completing one or more tasks, has just completedone or more previously-assigned tasks, and/or any other considerationassociated with the tasks that have been assigned to and/or completed bymobile drive unit 20 c.

Additionally, resource scheduling module 92 may determine the assignmentstate of a particular mobile drive unit 20 in any appropriate manner. Inparticular embodiments, mobile drive units 20, upon completing a task,notify resource scheduling module 92 of the fact that they havecompleted their currently assigned tasks. In the illustrated example,mobile drive unit 20 c notifies resource scheduling module 92 bytransmitting a task completion message 192. Task completion message 192indicates to resource scheduling module that the mobile drive unit 20that transmitted task completion message 192 has completed itscurrently-assigned task. Task completion message 192 may include anidentifier for the idle mobile drive unit 20 and/or other informationsuitable to allow resource scheduling module 92 to would otherwise haveto be prohibited from use in any paths may be selectively utilized inpaths for appropriate mobile drive units 20, thereby increasing thespace resources available to route planning module 94 for routingrequested paths 16.

Additionally, route planning module 94 may use the docking or loadingstatus of the requesting mobile drive unit 20 as a proxy for determiningthe urgency of the path 16 that mobile drive unit 20 is requesting. As aresult, in particular embodiments, route planning module 94 may decidenot to route undocked or unloaded mobile drive units 20 through cells inhigh-traffic areas even if the resulting path 16 is significantlylonger. Similarly, in particular embodiments, route planning module 94may decide not to generate paths for undocked or unloaded mobile driveunits 20 that require the use of scarce equipment resources, such asdrive lifts, to complete the paths. Consequently, route planning module94 may generate prioritized routes for certain mobile drive units 20based on the docking or loading status of those mobile drive units 20.

As another example, route planning module 94 may consider the power orfuel level of the requesting mobile drive unit 20 when generating path16. As a result, route planning module 94 may, based on the charge orfuel level of the requesting mobile drive unit 20, generate a path 16that is less than some maximum length to ensure the requesting mobiledrive unit 20 does not end up stranded, even if this path will increasethe probability that the requesting mobile drive unit 20 will be delayedby congestion. Similarly, route planning module 94 may decide based onthe fuel or charge level of the requesting mobile drive unit 20 togenerate a path that runs near a recharging or refueling station toallow the requesting mobile drive unit 20 to recharge or refuel while enroute to the destination location.

As yet another example, route planning module 94 may also consider thecurrent assignment state of a requesting mobile drive unit 20 ingenerating path 16 for that mobile drive unit 20. This assignment statemay relate to whether that mobile drive unit 20 is currently assigned atask, the priority of that task, and/or any other consideration relatingto the tasks currently or previously assigned to that mobile drive unit20. As a result, in particular embodiments, route planning module 94 mayonly route mobile drive units 20 that are currently assigned ahigh-priority task through what would otherwise be high-traffic cells14. Similarly, in particular embodiments, route planning module 94 maydecide to generate a path that requires use of scare equipmentresources, such as drive lifts, only if the requesting mobile drive unit20 is currently assigned a task or, alternatively, a high-priority task.Consequently, in particular embodiments, route planning module 94generates paths 16 that are quicker to complete for mobile drive units20 currently assigned a task, or for those currently assigned ahigh-priority task.

As yet another example, particular embodiments of inventory system 10may utilize mobile drive units 20 having different physicalcharacteristics, such as height and width. In such embodiments, routeplanning module 94 may be configured to consider the physicalcharacteristics of the requesting mobile drive unit 20 in generatingpath 16. As a result, in such an embodiment, the fact that it may bephysically impossible for certain mobile drive units 20 to move throughcertain cells 14, follow certain paths 16, or use certain equipment, maynot cause route planning module 94 to forgo use of such cells 14, paths16, or equipment when generating paths for all mobile drive units 20.

In general, however, route planning module 94 may, in particularembodiments, consider any one or more aspects of the state of mobiledrive unit 20, or of the load that mobile drive unit 20 is carrying, ingenerating a requested path 16. Consequently, route planning module 94may, in particular embodiments, be able to further optimize the use ofresource in inventory system 10 by tailoring path 16 to meet therequirements of the requesting mobile drive unit 20. Furthermore, byconsidering both the destination provided by mobile drive unit 20 andthe state of the requesting mobile drive unit 20 in generating path 16,certain embodiments of route planning module 94 may be able tofacilitate the completion of a second goal (such as recharging) withlittle or no impact on the ability of mobile drive unit 20 to completeits assigned task. As a result, particular embodiments of inventorysystem 10 that implement the techniques described with respect to FIG. 7may provide a number of operational benefits.

FIG. 8 is a flowchart illustrating operation of an example embodiment ofroute planning module 94 in implementing some or all of the techniquesdescribed with respect to FIG. 7. While FIG. 8 focuses on a particularembodiment of inventory system 10 that considers a particular aspect ofthe state of a mobile drive unit 20 in generating a path 16 to aparticular destination for that mobile drive unit 20, alternativeembodiments of inventory system 10 may be configured to consider anyappropriate aspect of the state of mobile drive units 20 when generatingpaths 16. Additionally, any of the steps illustrated in FIG. 8 may becombined, modified, or deleted where appropriate, and additional stepsmay also be added to those shown in the flowchart. Moreover, thedescribed steps may be performed in any suitable order without departingfrom the scope of the invention.

Operation begins at step 640 with route planning module 94 receiving aroute request 22 from a mobile drive unit 20. Route request 22identifies a destination location within workspace 70. In particularembodiments, workspace 70 comprises at least one cell 14 associated witha first cell attribute and at least one cell that is not associated withthe first cell attribute. For example, in particular embodiments, thosecells 14 which require tunneling to traverse are associated with atunneling attribute, while those cells which do not require tunnelingare not associated with the tunneling attribute. In the illustratedexample, all storage cells 64 in workspace 70 are associated with thetunneling attribute, and therefore require an mobile drive unit 20 to betunneling to traverse them. By contrast, all cells 14 that are notstorage cells 64 (“non-storage cells”) in workspace 70 are notassociated with the tunneling attribute, and these non-storage cells 64can be traversed without tunneling.

At step 642, route planning module 94 determines a state of the mobiledrive unit 20. As discussed above, route planning module 94 maydetermine the state of mobile drive unit 20 based on informationincluded in route request 22 or other communication with the requestingmobile drive unit 20, information maintained by route planning module94, information received from another component of inventory system 10,and/or any other suitable information. In response to determining thatthe requesting mobile drive unit 20 is associated with a first state,route planning module 94 generates a path 16 to the destination locationfor mobile drive unit 20 that may traverse cells 14 that are associatedwith the first cell attribute at step 644. In this case, the generatedpath 16 may traverse both cells that are associated with the first cellattribute and cells that are not associated with the first cellattribute. In response to determining mobile drive unit 20 is notassociated with the first state, however, route planning module 94generates a path 16 to the destination location for mobile drive unit 20that does not traverse any cells 14 associated with the first cellattribute at step 646. In this case, the generated path 16 traversesonly cells that are not associated with the first cell attribute. While,in particular embodiments, the generated path 16 may allow for aparticular mobile drive unit 20 to enter and exit a cell associated withthe first cell attribute from the same direction (e.g. to drop off aninventory holder 30 in an empty storage cell 64) the generated path 16,in such embodiments, will not allow or require the requesting mobiledrive unit 20 to traverse any such cells 14.

For example, in particular embodiments, route planning module 94 maydetermine whether mobile drive unit 20 is currently in a docked orundocked state. If route planning module 94 determines at step 642 thatthe requesting mobile drive unit 20 is currently docked, route planningmodule 94 generates a path 16 between the first destination and thesecond destination that only includes cells 14 that are not designatedas storage cells 64, such as path 16 a in FIG. 7. Instead, if routeplanning module 94 determines that the requesting mobile drive unit 20is not currently docked, route planning module 94 may generate a path 16that includes cells 14 that are designated as storage cells 64 as wellas cells 14 that are designated as non-storage cells, such as path 16 bin FIG. 7.

After generating the appropriate path 16, route planning module 94communicates path 16 to the requesting mobile drive unit 20. In theillustrated example, route planning module 94 communicates the generatedpath 16 to the requesting mobile drive unit 20 by transmitting a routeresponse 24 to the requesting mobile drive unit 20 that specifies thegenerated path 16 at step 648. Route response 24 includes informationdefining the generated path 16. After receiving route response 24,mobile drive unit 20 may then begin traversing the generated path 16 tothe destination location, and the operation of route planning module 94with respect to generating this path 16 ends, as shown in FIG. 8.

FIGS. 9-11 illustrate techniques for selecting a destination for mobiledrive unit 20 based on the state of the relevant mobile drive unit 20.More specifically, FIG. 9 illustrates an example of how managementmodule 15 might utilize such techniques to select destinations formobile drive units 20 based on their task assignments, while FIG. 10illustrates an example of how management determine that the relevantmobile drive unit 20 has completed its task. As a result, resourcescheduling module 92 determines the assignment state of mobile driveunit 20 c based on receipt of task completion message 192. Inalternative embodiments, resource scheduling module 92 may monitor oneor more mobile drive units 20 operating in workspace 70 and may maintainthe relevant state information as part of its normal operation.

In response to determining that mobile drive unit 20 c has completed itsassigned tasks, resource scheduling module 92 selects a destination formobile drive unit 20 c that is chosen based on the fact that mobiledrive unit 20 c is idle. Depending on the configuration of inventorysystem 10, resource scheduling module 92 may use the knowledge thatmobile drive unit 20 c is idle in any suitable manner in selecting anappropriate destination for mobile drive unit 20 c. By providing specialtreatment for idle mobile drive units 20, resource scheduling module 92may selectively place these mobile drive units 20 to improve the overalleffectiveness of inventory system 10.

In particular embodiments, resource scheduling module 92 may directmobile drive unit 20 c to low-traffic locations to prevent mobile driveunit 20 c from creating congestion while it awaits another task. As oneexample, resource scheduling module 92 may select a destination locationfrom among storage cells 64 that currently hold a stored inventoryholder 30. Storage cells 64 c, 64 d, and 64 e in FIG. 9 illustrateexamples of such locations.

As another example, resource scheduling module 92 may direct mobiledrive unit 20 c to a low-traffic destination by selecting a cell 14 thatis otherwise inaccessible by mobile drive units 20, as a destinationand/or to move through, that are currently docked with an inventoryholder 30. For example, in particular embodiments, resource schedulingmodule 92 may identify a destination from among cells 14 in workspacesthat have overhanging staircases, narrow entryways, low ceilings, and/orare otherwise inaccessible by mobile drive units 20 docked with theinventory holders 30 used in that embodiment of inventory system 10.This may help ensure that mobile drive units 20 transporting inventoryholders 30 will not need to use the cell 14 selected as a parking spacefor mobile drive unit 20 c. Workspace 70 illustrated in FIG. 9 includesa stairway 890 that prevents mobile drive units 20 transportinginventory holders 30 from moving through at least cells 14 c-14 g. As aresult, cells 14 c-14 g illustrate an example of this type ofinaccessible cell in FIG. 9.

As yet another example, in particular embodiments resource schedulingmodule 92 may direct mobile drive unit 20 c to a low-traffic destinationby selecting a destination location based on the actual traffic flowthrough the relevant area. For example, resource scheduling module 92may consider the frequency with which a particular cell 14 is includedin paths 16 generated by route planning module 94, the frequency withwhich segments that include that cell 14 are requested for reservation,and/or any other appropriate indicator of traffic flow, and may thenselect a destination for mobile drive unit 20 c from among cells 14 thatare only infrequently used by mobile drive units 20. Cells 14 h-14 j inFIG. 9 are assumed, for the purposes of this example, to be infrequentlyused by mobile drive units 20 and thus illustrate an example of thistype of location.

Additionally, resource scheduling module 92 may attempt to improveoperation of inventory system 10 by placing mobile drive unit 20 c in anoptimal position for responding to subsequent tasks assigned to mobiledrive unit 20 c. For example, in particular embodiments, resourcescheduling module 92 may select a destination location for mobile driveunit 20 c that is close to stored inventory holders 30. Cells 14 k-14 lin FIG. 9 illustrate generic examples of this type of location.

Furthermore, in particular embodiments, resource scheduling module 92may select a destination for mobile drive unit 20 c that is close tofrequently-requested inventory holders 30. For example, in a mail-orderwarehouse, resource scheduling module 92 may select a destination formobile drive unit 20 c near inventory holders 30 that store top-sellinginventory items 40. As a result, in such embodiments, resourcescheduling module 92 may consider the frequency with which particularinventory holders 30 are used in responding to inventory requests andselect a location for mobile drive unit 20 c that is near afrequently-requested inventory holder 30. Moreover, in particularembodiments, resource scheduling module 92 may attempt to achieve bothgoals by selecting a destination for mobile drive unit 20 c that islocated in a storage cell 64 that holds a frequently-requested inventoryholder 30. As a result, mobile drive unit 20 c may be kept out oftraffic and also optimally positioned for responding to subsequent taskslikely to be assigned to mobile drive unit 20. For the purposes of thisexample, inventory holders 30 m and 30 n are assumed to befrequently-requested inventory holders. As a result, due to the factthat storage cells 64 m and 64 n are each currently storing an inventoryholder 30 and, in particular, an inventory holder 30 that is frequentlyrequested, storage cells 64 m and 64 n in FIG. 9 represent examplelocations that satisfy both goals.

More generally, resource scheduling module 92 may select any particulartype of location as a destination for a mobile drive unit 20 having aparticular assignment status. Additionally, while FIG. 9 illustrates anexample configuration in which particular types of cells 14 that may beselected as destinations are located in particular locations inworkspace 70, resource scheduling module 92 may utilize destinations ofany type located anywhere within workspace 70.

After selecting a destination for mobile drive unit 20 c, resourcescheduling module 92 communicates the destination location to mobiledrive unit 20 c. In the illustrated embodiment, resource schedulingmodule 92 transmits a task assignment 18 that identifies the selecteddestination location. In particular embodiments, mobile drive unit 20 cmay then request a path and move to the destination, as described withrespect to FIG. 5. In particular embodiments, mobile drive unit 20 maythen wait at the destination until receiving another task assignment 18.

Thus, by selecting parking locations in low-traffic areas for idlemobile drive units 20, a particular embodiment of resource schedulingmodule 92 may reduce the probability that such mobile drive units 20will create congestion while they wait for further assignments.Furthermore, by placing idle mobile drive units 20 near inventoryholders 30 or other appropriate components of inventory system 10,resource scheduling module 92 can reduce the completion time for futuretasks that idle mobile drive units 20 are assigned. More generally, aparticular embodiment of inventory system 10 may be configured to usethe knowledge that a particular mobile drive unit 20 is idle in anyappropriate manner to select a destination for that mobile drive unit20. By strategically placing mobile drive units 20 when they are notbeing used, resource scheduling module 92 can further increase theoverall efficiency and throughput of inventory system 10.

FIG. 10 illustrates another example of how resource scheduling module 92may use various aspects of the state of a mobile drive unit 20 todetermine a location for that mobile drive unit 20. More specifically,FIG. 10 illustrates how resource scheduling module 92 may use acapability state of a mobile drive unit 20 to determine a location forthat mobile drive unit 20. By determining an appropriate destination fora mobile drive unit 20 based on the repair status, energy supply status,and/or any other consideration relating to the ability of that mobiledrive unit 20 to complete assigned tasks, in general, and/or to completea particular assigned task, resource scheduling module 92 may optimizethe placement of mobile drive units 20 in need of repair, re-supply,and/or other types of maintenance to regain or improve their capabilityof completing assigned tasks.

The example illustrated by FIG. 10 begins with resource schedulingmodule 92 determining the state or a particular aspect of the state ofmobile drive unit 20 d. In particular, in this example, resourcescheduling module 92 determines a capability state of mobile drive unit20 d. The capability state may relate to the repair status, supplystatus, maintenance status, and/or any other aspect of the mobile driveunits current ability or anticipated future ability to complete assignedtasks.

Resource scheduling module 92 may determine the capability state ofmobile drive unit 20 d in any appropriate manner. In the illustratedembodiment, mobile drive units 20 d is configured to transmit acapability message 990 when its capabilities change and/or an eventaffecting its capabilities occurs. For example, a mobile drive unit 20may transmit a capability message 990 when its fuel level or batterycharge level drops, parts or components of mobile drive unit 20 d breakor become unusable, a scheduled maintenance period for mobile drive unit20 d elapses, or any other event occurs affecting or potentiallyaffecting the ability of mobile drive unit 20 d to complete assignedtasks and/or remain active. In alternative embodiments, resourcescheduling module 92 may monitor various characteristics of mobile driveunits 20 or events associated with mobile drive units 20 as part of itsnormal operation and determine the capability state of mobile driveunits 20 based on the monitored information. In yet other embodiments,resource scheduling module 92 may receive information from othercomponents of inventory system 10 from which resource scheduling module92 determines the capability state of mobile drive units 20. In general,however, resource scheduling module 92 may determine the capabilitystate of a particular mobile drive unit 20 using any appropriateinformation obtained from any suitable source.

Returning to the illustrated example, resource scheduling module 92,after determining the capability state of mobile drive unit 20 d fromcapability message 990, selects a location for mobile drive unit 20 dbased on this capability state. Resource scheduling module 92 thengenerates a task assignment 18 identifying the selected location andtransmits task assignment 18 to mobile drive unit 20 for completion. Byselecting a destination appropriate for mobile drive unit 20 based onits capability state, resource scheduling module 92 may be able toreduce the effects of damage, energy depletion, and other debilitatingoccurrences on the congestion, throughput, and responsiveness ofinventory system 10.

As one example, in particular embodiments, the capability state ofmobile drive unit 20 d may relate to its state of repair. If anycomponents, or a specific component, of mobile drive unit 20 d breaks orbecomes unusable, mobile drive unit 20 may transmit capability message990 to resource scheduling module 92. Resource scheduling module 92 maythen select a destination for mobile drive unit 20 based on theknowledge that mobile drive unit 20 d needs repair. In particularembodiments, inventory system 10 may include automated repair stations992 that are capable of repairing certain types of malfunctions orreplacing certain types of parts. For example, inventory system 10 mayinclude an automated repair station 992 that can replace blown tires,clean sensors, or perform other types of repairs with limited or nohuman involvement. In such embodiments, resource scheduling module 92may select a destination at or near an appropriate automated repairstation 992, such as cells 14 m, 14 n, and 14 o, in response todetermining mobile drive unit 20 d needs repair or, in response todetermining mobile drive unit 20 d needs a particular type of repair.

As another example, in particular embodiments, inventory system 10 mayinclude cells 14, such as cells 14 p and 14 q that provide easy accessfor human operators attempting to repair mobile drive units 20, andresource scheduling module 92 may be configured to send mobile driveunits 20 to these cells for at least certain types of repairs. Inparticular embodiments, such as the one illustrated in FIG. 10, some orall of workspace 70 may be enclosed by a wall, railing, or other barrierthat prevents or limits entry to workspace 70 and resource schedulingmodule 92 may select a destination near access points to workspace 70(such as doors 998 in FIG. 10). Alternatively or additionally, resourcescheduling module 92 may select a destination that is located away fromhigh-traffic areas, reserved for repair work, or otherwise situated toallow human operators safe and/or easy access to mobile drive unitsneeding repair. Thus, in response to determining drive unit 20 d needsrepair or, in response to determining mobile drive unit 20 d needs aparticular type of repair (e.g., a type of repair too complicated forautomated repair station 994), resource scheduling module 92 may selecta destination, such as cells 14 p and 14 q, for mobile drive unit 20 dthat is easily accessible to human operators.

As yet another example, in particular embodiments, the capability stateof mobile drive unit 20 d may relate to its fuel or charge level. Forexample, in particular embodiments, mobile drive unit 20 d may transmitcapability message 990 indicating its fuel level, battery charge, orother appropriate form of energy level to resource scheduling module 92.Resource scheduling module 92 may then select an appropriate destinationfor mobile drive unit 20 d based on this information. In particularembodiments, inventory system 10 may include one or more energy stations996 at which mobile drive units 20 may be recharged or refueled, receivea new battery, or otherwise receive additional energy for responding toassigned tasks. Thus, in response to determining drive unit 20 d needsrefueling or recharging, resource scheduling module 92 may select adestination, such as cells 14 r, 14 s, or 14 t, that is close to anappropriate energy station 996.

As yet another example, in particular embodiments, resource schedulingmodule 92 may be configured to send mobile drive units 20 that needrepair, refuel, or recharging to low-traffic cells 14. Consequently, insuch embodiments, mobile drive units 20 that are not capable ofcompleting assigned tasks will not impede traffic while awaiting repairor removal from inventory system 10. In doing so, resource schedulingmodule 92 may consider the frequency with which a particular cell 14 isincluded in paths 16 generated by route planning module 94, thefrequency with which segments that include that cell 14 are requestedfor reservation, and/or any other appropriate indicator of traffic flow,and may then select a destination for mobile drive unit 20 d from amongcells 14 that are only infrequently used by mobile drive units 20.Additionally, when selecting a destination for such mobile drive units20, resource scheduling module 92 may consider the fact that, because ofphysical constraints, system policies, and/or any other suitableconsiderations a particular cell 14 is not otherwise available as adestination for mobile drive units 20 and/or for mobile drive units 20to move through. In FIG. 10, cells 14 u and 14 v in are assumed, for thepurposes of this example, to be infrequently used by mobile drive units20 and thus illustrate an example of this type of location. Thus, inresponse to determining drive unit 20 d needs repair or, in response todetermining mobile drive unit 20 d needs a particular type of repair,resource scheduling module 92 may select a destination in a low-trafficarea, such as cells 14 u or 14 v.

As yet another example, resource scheduling module 92 may select aparticular task or tasks for a mobile drive unit 20 based on thedegraded capabilities of mobile drive unit 20. Thus, when resourcescheduling module 92 detects that a mobile drive unit 20 is in a stateof disrepair, low on batteries or fuel, or otherwise in a state ofdegraded capabilities, resource scheduling module 92 may assign thatmobile drive unit 20 a task associated with lighter inventory holders30, inventory holders 30 closer to the position of the mobile drive unit20, or otherwise better suited for transport by the degraded mobiledrive unit 20 than the inventory holders 30 associated with other tasks.As a result, resource scheduling module 92 may select for the relevantmobile drive unit 20 a destination location associated with suchinventory holders 30.

More generally, resource scheduling module 92 may select any particulartype of location as a destination for a mobile drive unit 20 having aparticular capability state. Additionally, while FIG. 10 illustrates anexample configuration in which particular types of cells 14 that may beselected as destinations are located in particular locations inworkspace 70, resource scheduling module 92 may utilize destinations ofany type located anywhere within workspace 70.

After resource scheduling module 92 selects an appropriate destinationfor mobile drive unit 20 d based on its capability state, resourcescheduling module 92 communicates the destination to mobile drive unit20 d. In the illustrated example, communicates the destination bytransmitting a task assignment 18 to mobile drive unit 20 d thatidentifies the selected destination. Mobile drive unit 20 d thenrequests a path 16 to the selected destination and travels the path tothe selected destination as described above with respect to FIG. 5. Inparticular embodiments, mobile drive unit 20 may then remain at theselected destination until being repaired or receiving appropriatemaintenance. Mobile drive unit 20 may then become available to receiveother task assignments from resource scheduling module 92.

Although the above description focuses on an example in which mobiledrive unit 20 d transmits information indicating its capability state toresource scheduling module 92, in particular embodiments, resourcescheduling module 92 may instead determine the capability state of aparticular mobile drive unit 20 based on information resource schedulingmodule 92 retrieves from a source other than the relevant mobile driveunit 20. For example, in particular embodiments, mobile drive unit 20may be repaired or maintained according to a repair or maintenanceschedule, and resource scheduling module 92 may determine the capabilitystate of a particular mobile drive unit 20 based on this schedule andstored information indicating the last time the relevant mobile driveunit 20 was repaired or received maintenance.

Thus, by selecting parking spaces for mobile drive units 20 thatincrease the speed or ease with which mobile drive units 20 can berepaired, refueled, recharged, maintained, or otherwise have theircapabilities restored, resource scheduling module 92 can limit thenegative impact of mobile drive units 20 that are damaged, expended, orotherwise incapable of completing assigned tasks. Moreover, by choosingparking spaces in low-traffic areas for such mobile drive units 20,particular embodiments of resource scheduling module 92 may reduce theprobability that such mobile drive units 20 will create congestion whilethey await repair or maintenance. More generally, a particularembodiment of inventory system 10 may be configured to use the knowledgethat a particular mobile drive unit 20 is damaged, expended, orotherwise incapable of completing assigned tasks in any appropriatemanner to select a destination for that mobile drive unit 20. Bystrategically locating mobile drive units 20 that are in such a state,resource scheduling module 92 can further increase the overallefficiency and throughput of inventory system 10.

FIG. 11 is a flowchart illustrating the operation of a particularembodiment of resource scheduling module 92 in selecting a destinationlocation for a mobile drive unit 20. More specifically, FIG. 11illustrates the process by which resource scheduling module 92, inparticular embodiments of inventory system 10, selects a destination fora particular mobile drive unit 20 based on the state of that mobiledrive unit 20. Although FIG. 11 focuses on an example in which resourcescheduling module 92 selects a destination for mobile drive unit 20based on an assignment state of the mobile drive unit 20, particularembodiments of resource scheduling module 92 may be configured toinstead select a destination based on a capability state or any otheraspect of the overall state of the relevant mobile drive unit 20.Additionally, any of the steps illustrated in FIG. 11 may be combined,modified, or deleted where appropriate, and additional steps may also beadded to those shown in the flowchart. Moreover, the described steps maybe performed in any suitable order without departing from the scope ofthe invention.

Operation, in this example, begins with resource scheduling module 92determining an assignment state of a particular mobile drive unit 20 atstep 650. As noted above, the assignment state may relate to whether themobile drive unit 20 is currently assigned one or more tasks, isactively engaged in completing one or more tasks, and/or has justcompleted one or more previously-assigned tasks, and/or any other aspectof the tasks that have been assigned to and/or completed by mobile driveunit 20. At step 652, resource scheduling module 92 determines, based onthis assignment state, whether mobile drive unit 20 is currentlycompleting any assigned tasks. If resource scheduling module 92determines that mobile drive unit 20 is currently completing an assignedtask, resource scheduling module 92 may allow mobile drive unit 20 tocomplete its assigned task and operation of resource scheduling module92 with respect to selecting a destination for that mobile drive unit 20may end as shown in FIG. 11.

If, instead, resource scheduling module 92 determines that mobile driveunit 20 is not currently completing any assigned tasks, resourcescheduling module 92 selects a destination for mobile drive unit 20, atstep 654, based on the assignment state of mobile drive unit 20.Depending on the configuration of resource scheduling module 92,resource scheduling module 92 may select any appropriate destination formobile drive unit 20 based on its assignment state. In particularembodiments, resource scheduling module 92 may select a low-trafficdestination or a destination near locations associated with anticipatedfuture tasks. Thus, in response to determining that mobile drive unit 20is idle, resource scheduling module 92 may select a location based on atraffic level associated with the destination, based on its proximity toinventory holders 30, or based on any other consideration appropriate astate of the mobile drive unit 20.

At step 656, resource scheduling module 92 transmits informationidentifying the selected destination to mobile drive unit 20. Inparticular embodiments, resource scheduling module 92 transmits a taskassignment 18 that includes the selected destination. At step 658,mobile drive unit 20 moves to the selected destination.

Mobile drive unit 20 then waits until it receives another assigned taskat step 660. Thus, at step 662, mobile drive unit 20 determines whethermobile drive unit 20 has received another assigned task. If so, mobiledrive unit 20 begins executing the assigned task at step 664, and theoperation of resource scheduling module 92 with respect to selecting adestination for mobile drive unit 20 ends as shown in FIG. 11.

While mobile drive unit 20 is waiting for another assigned task,resource scheduling module 92 may determine, at step 666, that a portionof workspace 70 associated with the selected destination, such as a cell14 that contains the selected destination, is needed for another use. Asa result, resource scheduling module 92 may select another destinationfor mobile drive unit 20 at step 668, and operation may return to step656 with resource scheduling module 92 transmitting informationidentifying the newly-selected location to mobile drive unit 20.

FIGS. 12A-12E, 13, and 14 illustrate a technique for managing thecoordinated movement, or “platooning,” of mobile drive units 20. Morespecifically, FIGS. 12A-12E illustrate an example of how coordinatedmovement techniques might be implemented and utilized in a particularembodiment of inventory system 10. FIG. 13 is a flowchart illustratingexample operation of management module 15 in utilizing a particularimplementation of these techniques, while FIG. 14 is a flowchartillustrating example operation of a mobile drive unit 20 in utilizing aparticular implementation of these techniques.

As one example of how such a technique might be implemented and utilizedin inventory system 10, management module 15 may employ modifiedreservation policies for a group of mobile drive units 20 that aremoving in the same direction. In particular, one or more mobile driveunits 20 in the rear of the group may be allowed to reserve a segment 17that includes a particular cell 14 occupied by the mobile drive unit 20in front of that mobile drive unit 20 before the front mobile drive unit20 vacates the relevant cell 14, based on the expectation that themobile drive unit(s) 20 in the front will be moving at the same timethat the mobile drive unit(s) 20 in the back are moving and that, as aresult, a collision will not occur despite the relaxed reservationpolicy.

FIGS. 12A-12B illustrate an example of how these policies might beimplemented in the case of mobile drive units 20 that are not moving inthe same direction. More specifically, FIGS. 12A-12B show an example inwhich mobile drive unit 20 e is attempting to reserve a path segment 17x to move in the direction indicated by arrow 401. In the illustratedexample, segment 17 x is presently reserved and occupied by mobile driveunit 20 f. Moreover, mobile drive unit 20 e is attempting to movetowards mobile drive unit 20 f as indicated by arrow 402. FIGS. 12A and12B also show a drive identification signal 430 that is generated bymobile drive unit 20 f and described in greater detail below withrespect to FIGS. 12C-12E.

FIG. 12A shows the location of mobile drive units 20 e and 20 f, in thisexample, when mobile drive unit 20 e attempts to reserve segment 17 x.As shown in FIG. 12A, mobile drive unit 20 e attempts to reserve segment17 x by transmitting reservation request 26 to management module 15.Similar to the result under the reservation policies described abovewith respect to FIG. 5, this reservation request 26 will be denied evenunder the modified reservation policies utilized in this example,because mobile drive unit 20 f already occupies cell 14 xx on therequested segment 17 x and mobile drive unit 20 e and mobile drive unit20 f are not moving in the same direction. In the illustrated example,management module 15 notifies mobile drive unit 20 e that the attemptedreservation was unsuccessful by transmitting reservation response 28indicating that the reservation was unsuccessful, as shown in FIG. 12B.

Additionally, in particular embodiments, mobile drive units 20 e may beequipped with an obstacle sensor that senses objects in the path ofmobile drive unit 20 e, including other mobile drive units 20. As aresult, mobile drive unit 20 e may stop moving if mobile drive unit 20 edetects mobile drive unit 20 f in its path while in transit, or mayrefrain from requesting a reservation if mobile drive unit 20 e detectsmobile drive unit 20 f on a segment 17, such as segment 17 x, thatmobile drive unit 20 e is attempting to reserve. Consequently, inparticular embodiments, mobile drive unit 20 e may not even attempt toreserve segment 17 x if mobile drive unit 20 e detects mobile drive unit20 f on segment 17 x as is shown in the example.

FIGS. 12C-12E illustrate an example of how the modified policies mightoperate in the case of mobile drive units 20 that are moving in the samedirection. In FIGS. 12C-12E, mobile drive unit 20 e is again attemptingto reserve path segment 17 x to move in the direction indicated by arrow401. As in the previous illustrations, segment 17 x is already reservedand occupied by mobile drive unit 20 f. In this case, however, mobiledrive unit 20 f is attempting to move away from mobile drive unit 20 eas indicated by arrow 403.

FIG. 12C shows the location of mobile drive units 20 e and 20 f whenmobile drive unit 20 e attempts to reserve segment 17 x. As shown inFIG. 12C, mobile drive unit 20 e again attempts to reserve segment 17 xby transmitting a reservation request 26 to management module 15. Inthis case, however, segment reservation module 96 (or anotherappropriate component of management module 15) determines that mobiledrive unit 20 f is moving in the same direction as mobile drive unit 20e. As a result, segment reservation module 96 decides that it isacceptable to allow mobile drive unit 20 e to reserve segment 17 xsooner than mobile drive unit 20 e would otherwise be able to do so. Asa result, management module 15 may transmit a reservation response 28indicating that mobile drive unit 20 f has successfully reserved segment17, as shown in FIG. 12D.

Consequently, in particular embodiments, mobile drive unit 20 e may beable to successfully request reservations that overlap with thereservations of mobile drive unit 20 f based on the fact that mobiledrive units 20 e and 20 f are moving in the same direction as oneanother. Additionally, depending on the specific policies implemented bythe relevant embodiment of inventory system 10, mobile drive unit 20 emay also be permitted to move into a given cell 14 earlier than wouldotherwise be allowed. As a result, in particular embodiments, mobiledrive unit 20 e may, at particular times during its movement alongsegment 17 x, occupy a portion of the same cell 14 as mobile drive unit20 e, as shown in FIG. 12E. Thus, the modified reservation policiesshown in FIGS. 12C-12E allow for mobile drive units 20 traveling in thesame direction to follow one another with a much smaller distanceseparating them than would otherwise be allowed.

Additionally, as noted above, mobile drive unit 20 e may also include acollision detector capable of detecting obstacles in its way. If thecollision detector detects an obstacle in the path of mobile drive unit20 e, the collision detector may prevent mobile drive unit 20 e frommoving even if mobile drive unit 20 e has successfully reserved thesegments 17 in its path. Therefore, in embodiments of inventory system10 in which mobile drive units 20 utilize such collision detectors,mobile drive units 20 may also be configured to transmit a driveidentification signal 430, as shown in FIGS. 12A-12E.

Drive identification signal 430 may represent any appropriate form ofsignal that indicates to other mobile drive units 20 that the objecttransmitting drive identification signal 430 is itself a mobile driveunit 20. Examples of drive identification signals include, but are notlimited to, audio, visible light, radio, infra-red, and ultravioletsignals. In particular embodiments, drive identification signal 430 maycomprise a line-of-sight signal, and mobile drive units 20 may transmitdrive identification signal 430 in a direction opposite the direction inwhich they are traveling. As a result, only mobile drive units 20positioned behind the transmitting mobile drive unit 20 (relative to thedirection the transmitting mobile drive unit 20 is traveling) will beable to detect drive identification signal 430. Consequently, mobiledrive units 20 that do detect drive identification signal 430 candetermine, based on this detection, that the obstacle they are detectingis in fact a mobile drive unit 20 moving away from them and these mobiledrive units 20 may override their collision detectors as a result ofthis determination.

Furthermore, in addition to identifying the transmitting mobile driveunit 20 as a mobile drive unit, drive identification signal 430 maycarry additional information about the transmitting mobile drive unit 20to allow any nearby mobile drive unit 20 to modify its movement based onthe movement or planned movement of the transmitting mobile drive unit20. For example, drive identification signal 430 may contain the currentspeed, current acceleration/deceleration, destination, size, and/orlocation of the transmitting mobile drive unit 20 and/or any otherappropriate information to be used by mobile drive units 20 trying tonavigate within the vicinity of the transmitting mobile drive unit 20.As a result, when the transmitting mobile drive unit 20 adjusts itsspeed or direction, mobile drive units 20 following behind it can detectthis adjustment based on information contained in drive identificationsignal 430. The trailing mobile drive units 20 may then adjust their ownspeed in response and avoid collisions when the transmitting mobiledrive unit 20 brakes or otherwise decelerates.

Thus, in the example illustrated by FIGS. 12C-12E, mobile drive unit 20f transmits drive identification signal 430 that informs mobile driveunit 20 e that mobile drive unit 20 f is a mobile drive unit 20 and thatit is traveling at a particular speed. When mobile drive unit 20 edetects drive identification signal 430 transmitted by mobile drive unit20 f, mobile drive unit 20 e determines that the object detected by itscollision detector is in fact a mobile drive unit 20 moving in theopposite direction. As a result, mobile drive unit 20 e overrides itscollision detector and proceeds in the direction of mobile drive unit 20f, as shown by the dotted-line silhouette in FIG. 12E. As mobile driveunit 20 f adjusts its speed, mobile drive unit 20 e detects the changebased on information in drive identification signal 430 and adjusts itsown speed to match. As a result, mobile drive unit 20 e is able tofollow closely behind mobile drive unit 20 f while they are traveling inthe same direction while limiting or eliminating the possibility of acollision between mobile drive units 20 e and 20 f.

FIG. 13 is a flowchart illustrating example operation of segmentreservation module 96 in implementing the techniques described above. Inparticular, FIG. 13 details operation of a particular embodiment ofsegment reservation module 96 in managing the movement of a first mobiledrive unit 20 and a second mobile drive unit 20 that may be operating inclose proximity to one another. Any of the steps illustrated in FIG. 13may be combined, modified, or deleted where appropriate, and additionalsteps may also be added to those shown in the flowchart. Moreover, thedescribed steps may be performed in any suitable order without departingfrom the scope of the invention.

Operation begins, at step 670, with resource scheduling module 92receiving, from first mobile drive unit 20, a reservation request 26requesting use of a path segment 17 to move in a first direction. Priorto or after receiving reservation request 26, resource scheduling module92 determines that a second mobile drive unit 20 is currently located onthe requested path segment 17 at step 672. Because the second mobiledrive unit 20 is currently located on the requested path segment 17,resource scheduling module 92 determines whether the second mobile driveunit 20 is moving in the first direction at step 674.

If resource scheduling module 92 determines that the second mobile driveunit 20 is moving in the first direction, resource scheduling module 92grants the reservation. As a result, resource scheduling module 92reserves the requested path segment 17 at step 676. At step 678,resource scheduling module 92, in particular embodiments, then transmitsa reservation response 28 indicating that the requested reservation wassuccessful.

If resource scheduling module 92 determines that the second mobile driveunit 20 is not moving in the first direction, resource scheduling module92 denies the reservation. In particular embodiments, resourcescheduling module 92 may then transmit a reservation response 28 to thefirst mobile drive unit 20, at step 680, indicating that the firstmobile drive unit 20 did not successfully reserve the requested segment17. The operation of resource scheduling module 92 with respect toresponding to reservation request 26 may then end, as shown in FIG. 13.

FIG. 14 is a flowchart illustrating example operation of a mobile driveunit 20 in implementing the techniques described above. In particular,FIG. 14 details the decision-making utilized in particular embodimentsof inventory system 10 by a first mobile drive unit 20 operating inclose proximity to a second mobile drive unit 20. Any of the stepsillustrated in FIG. 14 may be combined, modified, or deleted whereappropriate, and additional steps may also be added to those shown inthe flowchart. Moreover, the described steps may be performed in anysuitable order without departing from the scope of the invention.

Operation begins at step 702 with the first mobile drive unit 20receiving a command instructing it to move in a first direction. Thiscommand may represent a task assignment 18 assigning mobile drive unit20 a task associated with a destination in the first direction, a routeresponse 24 identifying a path 16 heading in the first direction, and/orany other appropriate form of command instructing the first mobile driveunit 20 to move in the first direction. At step 704, the first mobiledrive unit 20 begins moving in the first direction along a path segment16.

At step 706, the first mobile drive unit 20 detects an object located inthe first direction along the path segment 16. In particularembodiments, mobile drive units 20 include an obstacle sensor 160capable of detecting objects in the paths of mobile drive units 20.Thus, in such embodiments, the obstacle sensor 160 of first mobile driveunit 20 may detect the object.

At step 708, the first mobile drive unit 20 determines whether thedetected object is another mobile drive unit 20 moving in the firstdirection. In particular embodiments, mobile drive units 20 transmitdrive identification signals 430 that identify them as mobile driveunits 20. Moreover, in particular embodiments, mobile drive units 20transmit drive identification signal 430 in a direction opposite theirdirection of travel. As a result, only mobile drive units 20 behind atransmitting mobile drive units 20 (relative to the direction of travelof the transmitting mobile drive unit 20) receive the driveidentification signal 430 transmitted by the transmitting mobile driveunit 20. Thus, in such embodiments, the first mobile drive unit 20 maydetermine whether the detected object is a second mobile drive unit 20moving in the first direction by determining whether the first mobiledrive unit 20 detects a drive identification signal 430 transmitted bythe object.

If the first mobile drive unit 20 determines that the detected object isnot a second mobile drive unit 20 traveling in the second direction, thefirst mobile drive unit 20 may terminate movement in the first directionat step 710. The first mobile drive unit 20 may then wait until thefirst mobile drive unit 20 no longer detects the detected obstacle inits path, move around the detected obstacle, request a new path, and/ortake any other remedial action appropriate based on the configuration ofthe first mobile drive unit 20. Operation may then end with respect tothis particular movement of the first mobile drive unit 20, as shown inFIG. 14.

If, instead, the first mobile drive unit 20 determines that the detectedobject is a second mobile drive unit 20 moving in the first direction,the first mobile drive unit 20 continues moving in the first direction.Additionally, in particular embodiments, the second mobile drive unit 20may communicate information regarding its current state to the firstmobile drive unit 20. For example, in particular embodiments, the driveidentification signal 430 transmitted by the second mobile drive unit 20may include information specifying the current speed of the secondmobile drive unit 20, its position, and the maximum rate of decelerationit can presently achieve. At step 712, the first mobile drive unit 20may then calculate a speed at which it can safely follow the secondmobile drive unit 20. In particular embodiments, first mobile drive unit20 may calculate this speed based on the state of first mobile driveunit 20 and/or the state of second mobile drive unit 20, as describedabove. At step 714, the first mobile drive unit 20 may continue movementin the first direction at the calculated speed. Operation may then endwith respect to this particular movement of the first mobile drive unit20, as shown in FIG. 14.

FIGS. 15 and 16 illustrate operation of a particular embodiment of routeplanning module 94 in utilizing various types of equipment in inventorysystem 10 to facilitate the movement of mobile drive units 20. Morespecifically, FIG. 15 illustrates a particular embodiment of inventorysystem 10 that includes conveyance equipment to supplement thecapabilities of mobile drive units 20 in transporting inventory holders30, while FIG. 16 illustrates an example of how route planning module 94may plan paths for mobile drive units 20 that rely on such equipment.Additionally, FIG. 17 is a flowchart illustrating example operation ofinventory system 10 in utilizing particular types of conveyanceequipment to transport inventory holders 30.

FIG. 15 illustrates an embodiment of inventory system 10 that includescertain types of conveyance equipment that route planning module 94 mayincorporate into paths 16 that route planning module 94 generates forrequesting mobile drive units 20. In general, inventory system 10 mayinclude any appropriate form of conveyance equipment to supplement thetransportation capabilities provided by mobile drive units 20. Suchconveyance equipment may include, but is not limited to, vertical lifts,horizontal conveyors, elevators, escalators, trucks, ferries, and/or anyother equipment capable of transporting inventory holders 30 and/ormobile drive unit 20 that are themselves transporting inventory holders30. As a result, particular embodiments of inventory system 10 thatinclude such conveyance equipment may be capable of providingalternative manners of conveyance unachievable by the particular type ofmobile drive unit 20 utilized in that embodiment of inventory system 10(e.g., transportation between floors of a multi-floored workspace 70 ortransportation between buildings in a multi-building workspace 70) ormay be capable of more efficiently providing transportation of inventoryholders 30 under certain conditions (e.g., scheduled transportation ofgroups of inventory holders 30 along high-traffic paths 16 or segments17).

To optimize use of such conveyance equipment, management module 15 mayimplement certain techniques for path planning, segment reservation,and/or other aspects of managing inventory system 10 that consider thecharacteristics, advantages, and/or limitations of the conveyanceequipment included in that particular embodiment of inventory system 10.FIG. 15 illustrates one example of techniques management module 15 mayutilize to reserve access to and use of particular types of conveyanceequipment for requesting mobile drive units 20. More specifically, FIG.15 illustrates an example of how management module 15 handlesreservation of drive lifts 790 in a multi-storied workspace 70 tofacilitate entry to, use of, and exit from drive lifts 790 by mobiledrive units 20.

Particular embodiments of inventory system 10, such as the one shown inFIG. 15, may utilize a workspace 770 that is spread over multipledifferent floors, rooms, and/or areas of a building or other structurethat are otherwise physically separated from one another. In suchembodiments, inventory holders 30, inventory stations 50, and/or otherelements of inventory system 10 may be spread over multiple differentfloors, rooms, and/or areas, and mobile drive units 20 may move betweenthese separate portions of workspace 770 to complete assigned tasks.Moreover, such embodiments may include alternative conveyance equipmentto supplement the transportation capabilities of mobile drive units 20in moving inventory holders 30 between the various portions of workspace770. For example, FIG. 15 illustrates an inventory system 10 thatincludes drive lifts 790 a-c to facilitate the movement of mobile driveunits 20 and inventory holders 30 between the various floors 772 ofworkspace 770. As a result, resource scheduling module 92, routeplanning module 94, and/or other components of management module 15 mayconsider the multi-floor nature of workspace 770 and the existence ofdrive lifts 790 when assigning tasks to mobile drive units 20, planningpaths to facilitate the completion of certain tasks, or performing anyother task relating to the management of inventory system 10.

In the illustrated embodiment, inventory system 10 utilizes a pluralityof drive lifts 790 that connect floors 772 a-c of a multi-floorworkspace 770. Drive lifts 790 a-c each connect a ground floor 772 a toa second-level floor 772 b and a third-level floor 772 c, as indicatedby arrows 792 a-c, respectively. Route planning module 94 is capable ofgenerating paths 16 for mobile drive units 20 that rely on drive lifts790 to facilitate the movement of mobile drive units 20 betweendifferent floors 772 of workspace 770. In particular embodiments, mobiledrive units 20 may then traverse these paths 16, as described above withrespect to FIG. 5, additionally reserving and using drive lifts 790 asappropriate to complete the received paths 16.

For the purposes of the illustrated example, mobile drive unit 20 g islocated on floor 772 a and is assumed to have received a path 16 m to adestination cell 14 located on floor 772 c. Path 16 m is assumed toutilize drive lift 790 b to transport mobile drive unit 20 g to floor772 c. After receiving path 16 m, mobile drive unit 20 may beginadvancing along the received path 16 m, reserving segments and moving asdescribed above with respect to FIG. 5. At an appropriate point alongpath 16 m, for example while traversing segment 17 m, mobile drive unit20 may attempt to reserve a segment 17 n associated with drive lift 790b.

Because the use of drive lifts 790 may require that certain conditionsbe satisfied to ensure that mobile drive units 20 are capable of safelyentering and exiting drive lifts 790, segment reservation module 96 maybe configured to consider the fact that a particular requested cell 14or segment 17 is adjacent to or associated with a drive lift 790 whenresolving reservations of that cell 14 or segment 17. As one example, inparticular embodiments, resource scheduling module 92 may group cells 14adjacent to a particular drive lift 790 on the various floors 772 ofworkspace 770 into a single group. In such embodiments, resourcescheduling module 92 may grant use of the cells 14 and the associateddrive lift 790 to a single mobile drive unit 20 at a time. As a result,resource scheduling module 92 may be able to ensure that a particularrequesting mobile drive unit 20, after reserving a particular drive lift790, is able to exit drive lift 790 on any floor 772 without thepossibility of another mobile drive unit 20 blocking the requestingmobile drive unit 20 from exiting the relevant drive lift 790, eitherphysically or by reserving a cell 14 the requesting mobile drive unit 20must use to exit the relevant drive lift 790.

Thus, in the illustrated example, cells 14 w, 14 x, 14 y, and 14 z (theshaded cells 14 in FIG. 15) are all considered part of a cell group thatis associated with drive lift 790 b. As mobile drive unit 20 gapproaches drive lift 790 b while traversing path 16 m, mobile driveunit 20 g attempts to reserve cell 14 x by transmitting a reservationrequest 26 that identifies segment 17 n. Segment reservation module 96receives the reservation request 26 and determines that segment 17 nincludes a cell 14 w that contains drive lift 790 b. As a result,segment reservation module 96 attempts to satisfy the reservationrequest 26 by reserving all of the cells 14 in the group associated withdrive lift 790 b. More specifically, segment reservation module 96attempts to reserve cells 14 x, 14 y, and 14 z, as well as the requestedcell 14 w. In this embodiment, if segment reservation module 96determines that mobile drive unit 20 g cannot reserve all of cells 14w-14 z then segment reservation module 96 transmits a reservationresponse 28 indicating that the requested reservation response 28 wasunsuccessful. Mobile drive unit 20 may then take any appropriateremedial actions as described above with respect to FIG. 5. If, instead,segment reservation module 96 determines that mobile drive unit 20 g canreserve all of cells 14 w-14 z, then segment reservation module 96transmits a reservation response 28 indicating that the requestedreservation was successful.

Additionally, in particular embodiments, drive lift 790 may include onlya single platform or car and a mobile drive unit's ability to access thedrive lift 790 at a given time may depend on the floor 772 on which thecar or platform is located at that time. Thus, as part of determiningwhether a requesting mobile drive unit 20 can reserve a particular drivelift 790, segment reservation module 96 may determine whether theplatform or car is currently located on the same floor 772 as therequesting mobile drive unit 20. If not, segment reservation module 96may, depending on the configuration of inventory system 10, decline therequested reservation, grant the requested reservation but indicate thatmobile drive unit 20 must wait a particular amount of time beforeattempting to enter the relevant drive lift 790, or grant the requestedreservation and rely upon interaction between the relevant drive lift790 and the requesting mobile drive unit 20 (e.g., traffic signalstransmitted by the drive lift 790) to ensure that the requesting mobiledrive unit 20 waits until the drive lift 790 is appropriately positionedbefore entering.

Additionally, in particular embodiments, to improve the effectiveness ofdrive lifts 790, segment reservation module 96 may consider the currentposition of a car or platform of a particular drive lift 790 whendeciding which of competing mobile drive units 20 to grant use of thatdrive lift 790. As an example, in particular embodiments, segmentreservation module 96 may reduce movement of the car or platform whileempty by granting mobile drive units 20 located on the current floor ofthe car or platform priority in reserving use of the car or platform.Thus, if two mobile drive units 20 both request use of the same drivelift 790 at approximately the same time, segment reservation module 96may give priority to the reservation of the mobile drive unit 20 that islocated on the same floor that the car or platform of the relevant drivelift 790

Returning to the example, drive lift 790 b is appropriately configuredfor use by mobile drive unit 20 g, mobile drive unit 20 g may enterdrive lift 790 b. Drive lift 790 b may then transport mobile drive unit20 g to floor 772 c. Mobile drive unit 20 g may then exit drive lift 790b into cell 14 z, which, in this example, mobile drive unit 20 g hasalready reserved by virtue of reserving cell 14 w and/or use of drivelift 790 b.

Additionally, in particular embodiments, mobile drive units 20 may becapable of receiving new tasks and/or paths 16 while being transportedbetween floors 772. As a result, the fact that mobile drive units 20,when using a particular drive lift 790, reserve a group of cells 14appropriate to allow exit and entry to that drive lift 790 on any floor772 may, in particular embodiments, allow mobile drive unit 20 to adjustquickly to the new task or path 16 and exit the relevant drive lift 790on a different floor 772 without being blocked by mobile drive units 20on the new floor 772. For example, mobile drive unit 20 g may receive anew task and/or path 16 requiring mobile drive unit 20 to exit drivelift 790 on floor 772 b. As a result of the fact that mobile drive unit20 g previously reserved all of the cells 14 in the group associatedwith drive lift 790 b, another mobile drive unit 20 will not be blockingcell 14 y physically or by reservation, if mobile drive unit 20 gattempts to change its path and exit on floor 772 b. This, in turn, mayprevent mobile drive unit 20 g from monopolizing lift 772 b despite itssudden change in route.

Returning to the illustrated example, once drive lift 790 b transportsmobile drive unit 20 g to floor 772 c, mobile drive unit 20 g exitsdrive lift 790 b. As noted above, in particular embodiments, mobiledrive unit 20 has already reserved cell 14 z as part of its initialreservation. In such embodiments, that reservation will ensure cell 14 zis clear and mobile drive unit 20 can immediately disembark from drivelift 790. Mobile drive unit 20 may then proceed with completing theremainder of path 16 m as described above with respect to FIG. 5.

By reserving an entrance and multiple possible exits from drive lifts790 for mobile drive units 20 using those drive lifts 790, segmentreservation module 96 may limit traffic congestion and reduce the amountof time mobile drive units 20 are forced to wait before exiting drivelifts 790. Additionally, this reservation system may prevent a blockedmobile drive unit 20 from delaying use of a drive lift 790 by othermobile drive units 20. Furthermore, by considering the current locationof a car or lift of a drive lift 790 in granting reservations, segmentreservation module 96 may limit the number of unloaded transitions thecar or platform makes between floors 772 and increase the drive lifts790 throughput. As a result, the described techniques may facilitatemore efficient operation of drive lifts 790 and mobile drive units 20.

FIG. 16 illustrates further certain techniques that particularembodiments of inventory system 10 may implement to optimize the use ofconveyance equipment, such as drive lifts 790, to supplement theoperation of mobile drive units 20 in transporting inventory holders 30.More specifically, FIG. 16 illustrates certain techniques particularembodiments of inventory system 10 may utilize to ensure that thebenefits and drawbacks of using a particular type conveyance are weighedin planning the tasks that will be assigned and the routes that mobiledrive units 20 will take when moving within workspace 70. As a result,particular embodiments of inventory system 10 may further increase theefficiency that may result from the availability and use of conveyanceequipment to assist mobile drive units 20 in transporting inventoryholders 30.

For example, in particular multi-story embodiments of inventory system10, resource scheduling module 92 may associate a cost with the use ofeach cell 14 in workspace 770. This cost may represent the time expendedin driving across the cell 14, the historical level of congestion withinthe cell 14 or neighboring cells 14, the number of inventory holders 30adjacent to the cell, and/or any other consideration that may reflectthe cost in time, space, and/or other resources that is associated withrouting a mobile drive unit 20 through the relevant cell 14. Likewise,resource scheduling module 92 may associate a cost with the use of drivelifts 790 and/or other equipment used to facilitate movement of mobiledrive units 20 such as conveyors, escalators, and/or cranes. Using drivelifts 790 as an example, this cost may represent the time expended inriding drive lift 790 between particular floors 772, the power expendedin operating drive lift 790, the frequency with which multi-floor pathsusing that drive lift 790 are otherwise generated by resource schedulingmodule 92, and/or any other consideration that may reflect the cost intime, space, and/or other system resources that is associated withproviding mobile drive unit 20 a path 16 that utilizes the relevantdrive lift 790.

When management module 15 receives an inventory request identifying, forexample, a particular inventory item 40 to be retrieved, resourcescheduling module 92 may select an inventory holder 30 based, at leastin part, on the least-costly route to each of the inventory holders 30currently storing the requested inventory item 40. Consequently, inparticular embodiments, resource scheduling module 92 may add up thetotal cost associated with every possible path 16 between the currentlocation of the relevant mobile drive unit 20 and a particular inventoryholder 30 storing the relevant inventory item 40. Resource schedulingmodule 92 may then compare the cost of the least expensive path betweenthe mobile drive unit 20 and each inventory holder 30 and select aninventory holder 30 based, at least in part, on the least costly path 16between a selected mobile drive unit 20 and each of the inventoryholders 30.

To illustrate, FIG. 16 shows an example in which management module 15selects an inventory holder 30 to be used in satisfying an inventoryrequest requesting a particular inventory item 40. In the example,resource scheduling module 92 has already selected mobile drive unit 20h based on appropriate criteria to retrieve an inventory holder 30containing the requested inventory item 40. Inventory holders 30 p and30 q are the only inventory holders 30 currently storing the requestedinventory item 40. Additionally, for the purposes of this example, it isassumed that path 16 p and path 16 q are the least costly paths 16between mobile drive unit 20 h and inventory holder 30 p and 30 q,respectively. As a result, resource scheduling module 92 selects one ofinventory holder 30 p and 30 q based, at least in part, on the costassociated with path 16 p and 16 q.

Consequently, if the cost associated with path 16 p is greater than thecost associated with path 16 q, resource scheduling module 92 willselect inventory holder 30 q, and mobile drive unit 20 h, in thisexample, will be required to use one of drive lifts 790 to access floor772 b when retrieving inventory holder 30 q. If however, the costassociated with using drive lift 790 and traversing the cells 14 on path16 q exceed the cost of traversing cells 14 on path 16 p, resourcescheduling module 92 will select inventory holder 30 p. Thus, resourcescheduling module 92, in particular embodiments, is capable ofrecognizing that one or more costs of using drive lifts 790 may make theuse of drive lifts 790 less preferred in many cases, but that, undercertain circumstances, the benefits of using drive lifts 790 mayoutweigh these costs.

After selecting an inventory holder 30 to be retrieved, resourcescheduling module 92 communicates the location of the selected inventoryholder 30 to mobile drive unit 20 h, for example, as part of a taskassignment 18, as described above. Assuming, for the purpose of thisexample, that resource scheduling module 92 has selected inventoryholder 30 q, mobile drive unit 20 h requests a path 16 to inventoryholder 30 q from route planning module 94. In response, route planningmodule 94 communicates path 16 q or, if routing considerations havechanged since inventory holder 30 q was selected, another path 16 toinventory holder 30 q.

Upon receiving a suitable path 16 to inventory holder 30 q, mobile driveunit 20 h reserves a first segment 17 of the received path 16 and beginsmoving towards inventory holder 30 q as described above with respect toFIG. 5. Assuming mobile drive unit 20 h received path 16 q from routeplanning module 94, mobile drive unit 20 h will move towards drive lift790 c along path 16 q. As mobile drive unit 20 h approaches drive lift790 c, mobile drive unit 20 h may attempt to reserve drive lift 790 c.In particular embodiments, mobile drive unit 20 h may reserve drive lift790 c in a similar manner as that described above for reserving segments17. Thus, if another mobile drive unit 20 h currently has drive lift 790c reserved and/or is currently on drive lift 790 c, mobile drive unit 20h may be unable to reserve drive lift 790 c.

Once mobile drive unit 20 h does successfully reserve drive lift 790 c,mobile drive unit 20 h may position itself on drive lift 790 c. Drivelift 790 c may then lift mobile drive unit 20 h to floor 772 b. As notedabove, operation of drive lifts 790 may be controlled by mobile driveunits 20, management module 15, or any other suitable components ofinventory system 10. After drive lift 790 c lifts mobile drive unit 20 hto floor 772, mobile drive unit 20 h proceeds to the location ofinventory holder 30 q and docks with inventory holder 30 q. Mobile driveunit 20 h may then request, from route planning module 94, a path 16back to an inventory station 50 associated with the inventory request.After receiving such a path 16, mobile drive unit 20 h may use a drivelift 790 specified by the received path 16 to return to floor 772 a andthen move inventory holder 30 q to the relevant inventory station 50 tocomplete the assigned task.

As a result, inventory system 10 may incorporate drive lifts 790 to liftand lower mobile drive units 20 thereby facilitating the use ofmulti-storied workspaces 770. Moreover, management module 15 and itsvarious components may be configured to consider the costs and benefitsof using drive lifts 790 and may, as a result, make knowledgeabledecisions regarding the use of drive lifts 790 to complete particulartasks. In a similar manner, inventory system 10 and management module 15may be configured to utilize other equipment (such as, for example,conveyors, escalators, cranes, or ferries) or features (such as, forexample, ramps, tunnels, or stairways) to facilitate the movement ofmobile drive units 20 within workspace 770. Additionally, the ability toeffectively incorporate such equipment into inventory system 10 mayallow greater flexibility in the size, shape, and configuration ofworkspace 770 and/or provide other benefits.

FIG. 17 is a flowchart illustrating the operation of a particularembodiment of resource scheduling module 92 in selecting paths formobile drive units 20 in a workspace 70 that utilizes conveyanceequipment in conjunction with mobile drive units 20 to transportinventory holders 30. While FIG. 17 focuses on a particular embodimentof inventory system 10 that utilizes a particular technique forreserving conveyance equipment, alternative embodiments of inventorysystem 10 may be configured to utilize conveyance equipment in anyappropriate manner. Additionally, any of the steps illustrated in FIG.17 may be combined, modified, or deleted where appropriate, andadditional steps may also be added to those shown in the flowchart.Moreover, the described steps may be performed in any suitable orderwithout departing from the scope of the invention.

Operation begins, in FIG. 17, with a mobile drive unit 20 moving to afirst point within a workspace 70 at step 720. In the described example,an inventory holder 30 is stored in a first cell 14 at the first point.After arriving at the first point, mobile drive unit 20 docks with theinventory holder 30 stored at the first point at step 722.

After docking with inventory holder 30, mobile drive unit 20 movesitself and the inventory holder toward a second point within theworkspace at step 724. In the illustrated example, the second point islocated in a second cell 14 that is associated with conveyanceequipment. This second cell 14 may represent a cell in which theconveyance equipment is located, an entry cell for the conveyanceequipment, a pick-up cell for the conveyance equipment, or a cellassociated with the conveyance equipment in any other manner.Additionally, in the described example, the conveyance equipment isassociated with a group of multiple cells 14 of which the second cell 14is a member.

As mobile drive unit 20 moves to the second point, or once mobile driveunit 20 arrives at the second point, mobile drive unit 20 reserves thesecond cell 14. In the described example, mobile drive unit 20 reservesthe second cell 14 by transmitting a reservation request 26 identifyingthe second cell 14 to segment reservation module 96 15 at step 726. Atstep 728, segment reservation module 96 receives reservation request 26.

After receiving reservation request 26, segment reservation module 96determines that the second cell 14 is a member of a group of cells 14that are associated with the conveyance equipment at step 730. As aresult, segment reservation module 96, as a response to receivingreservation request 26, attempts to reserve all of the cells 14 in thegroup of cells 14 associated with the conveyance equipment at step 732.Segment reservation module 96 then indicates to the requesting mobiledrive unit 20 whether segment reservation module 96 was able to reservethe second cell and/or all of the cells 14 in the group associated withthe conveyance equipment. In the described example, segment reservationmodule 96 communicates the outcome to mobile drive unit 20 bytransmitting a reservation response 28 at step 734.

After successfully reserving the group of cells 14 associated with theconveyance equipment, mobile drive unit 20 enters the second cell 14 atstep 736. At step 738, in the described example, the conveyanceequipment moves inventory holder 30 and mobile drive unit 20 to a thirdpoint. In alternative embodiments, the conveyance equipment may moveinventory holder 30 without moving mobile drive unit 20 and mobile driveunit 20 may undock from the inventory holder 30 at the second point.

After the conveyance equipment moves the inventory holder 30 and, ifappropriate, mobile drive unit 20 to the third point, mobile drive unit20 or another suitable component of inventory system 10 terminates thereservation of the group of cells 14 associated with the conveyanceequipment at step 740. In particular embodiments, the group of cells 14may include, at or near the third point, one or more exit cells 14,drop-off cells 14, and/or other appropriate cells 14 that are part ofthe group of cells 14 associated with the conveyance equipment and thereservation may be maintained until mobile drive unit 20 exits thosecells 14.

At step 742, the original mobile drive unit 20 or another mobile driveunit 20 moves inventory holder 30 to a fourth point. The fourth pointmay represent a storage location, inventory station 50, or otherappropriate destination associated with the relevant inventory holder30. For example, in the described example, the fourth point is locatedin a storage cell 64 intended for inventory holder 30. Thus, in thisexample, mobile drive unit 20 undocks from inventory holder 30 and movesaway from inventory holder 30 at step 744. In this example, operation ofinventory system 10 with respect to moving inventory holder 30 then endsas shown in FIG. 17.

FIGS. 18-20 illustrate example operation of an embodiment of inventorysystem 10 that utilizes specific techniques for rotating inventoryholders 30 as part of transporting inventory holders 30 within inventorysystem 10. These techniques may be useful, for example, in presenting aparticular face of an inventory holder 30 to an operator of an inventorystation 50. The described techniques and system configuration may allowparticular embodiments of inventory system 10 to operate withinworkspaces 70 having a reduced size and to simplify the coordination ofmobile drive unit movement. In particular embodiments of inventorysystem 10 that utilize inventory stations 50, the positioning ofrotation areas 790 near inventory stations 50 may allow managementmodule 15 to delay the selection of a face to be presented at aparticular inventory station 50 until the assigned mobile drive unit 20is near the inventory station 50. This may allow management module 15 tooptimize face selection based on the current state of inventory system10.

FIG. 18 illustrates an embodiment of inventory system 10 that includes amanagement module 15, one or more mobile drive units 20, one or moreinventory holders 30, and one or more inventory stations 50 that operatewithin a workspace 870 similar to those described above with respect toFIG. 1. Additionally, workspace 870 includes a plurality of rotationareas 892 in which mobile drive units 20 perform particular operationsassociated with rotating inventory holders 30. By performing some or allrotations of inventory holders 30 in rotation areas 892, particularembodiments of inventory system 10 may be configured to operate within asmaller workspace.

Rotation areas 892 represent a portion of workspace 870 covering aplurality of cells 14. In particular embodiments of inventory system 10,the number and arrangement of cells 14 in a particular rotation area 892are selected based on the size and shape of inventory holders 30 and thetype of rotational movement supported by mobile drive units 20. Forexample, in particular embodiments, inventory system 10 utilizesinventory holders 30 that include four similarly-dimensioned faces witheach face a having a width substantially equal to or slightly smallerthan the width of a cell 14 in workspace 870. Particular embodiments mayalso utilize mobile drive units 20 that are capable of three-hundred andsixty degree rotations while stationary. In such embodiments, workspace870 may include rotation areas 892 that represent a two-cell by two-cellsection of workspace 870. While FIG. 18 illustrates a particularembodiment in which rotation areas are equal in size to some wholemultiple of the size of an individual cell 14, alternative embodimentsof inventory system 10 may utilize rotation areas 892 having anysuitable size that is larger than the size of an individual cell 14.Additionally, although FIG. 18 illustrates a particular embodiment ofinventory system 10 in which rotation areas 892 are located adjacent toeach inventory station 50, alternative embodiments of inventory items 40may include any number of rotation areas 892 in any appropriate locationwithin workspace 870.

In the illustrated embodiment of inventory system 10, mobile drive units20 interact with management module 15 to receive task assignments,request paths 16, and reserve routed segments 17 in order to completetasks in a manner similar to that described above with respect to FIG.5. While transporting inventory holders 30 between locations inworkspace 870, a mobile drive unit 20 maintains a constant orientationfor inventory holders 30 regardless of the direction mobile drive unit20. Consequently, in the illustrated embodiment, when a mobile driveunit 20 changes the direction in which it is traveling, the orientationof an inventory holder 30 being transported by that mobile drive unit 20remains the same despite the direction change.

This may be accomplished in a variety of ways depending on theconfiguration and capabilities of mobile drive units 20. As one example,in particular embodiments, a mobile drive unit 20 may be capable ofpropelling itself in a forward and a backward direction relative to acertain face of mobile drive unit 20 and of rotating itself to changeits direction of travel. In such embodiments, mobile drive unit 20 mayundock from an inventory holder 30 it is currently transporting beforerotating and inventory holder 30 may, as a result, maintain a constantorientation regardless of the direction in which mobile drive unit 20 isdriving. As another example, in particular embodiments, mobile driveunit 20 is capable of propelling itself in any of four directions andcan thus change its direction of travel without rotating.

Because many shapes of inventory holders 30 require a greater amount ofspace between neighboring inventory holders 30 when one or more suchinventory holders 30 are rotated, limiting rotation of inventory holders30 can reduce the amount of space required for inventory holders 30 tobe transported within workspace 870 without collisions occurring betweeninventory holders 30. Nonetheless, in particular embodiments ofinventory system 10, a number of benefits may arise from mobile driveunits 20 rotating inventory holders 30. For example, inventory system 10may reduce the amount of time and effort that is spent by the operatorof an inventory station 50 in retrieving inventory items 40 from aparticular bin of an inventory holder 30 if inventory holder 30 isrotated so that the appropriate face of that inventory holder 30 ispresented to the operator.

Thus, in the illustrated embodiment of inventory system 10, mobile driveunits 20 may be configured to allow rotation of inventory holders 30 butto perform some or all such rotations in rotation areas 892. Inparticular, mobile drive units 20 assigned tasks that involvetransporting inventory holders 30 to inventory stations 50 may bringinventory holders 30 towards inventory station 50, maintaining aconstant orientation for inventory holders 30 as described above. Mobiledrive units 20 may then, if appropriate, execute one or more stepsdesigned to induce a certain form of rotation in inventory holder 30suitable to present a particular face of the retrieved inventory holder30 to inventory station 50. FIGS. 19A to 19E illustrate examples of thesteps particular embodiments of mobile drive units 20 may execute toinduce specific types of rotation in inventory holders 30. Aftercompleting the appropriate form of rotation, mobile drive unit 20 maythen position inventory holder 30 in front of inventory station 50 toallow an operator of inventory station 50 to access the presented faceof inventory holder 30.

Consequently, by restricting or eliminating the ability of mobile driveunits 20 to rotate inventory holders 30 outside of rotation areas 892,particular embodiments of inventory system 10 may be able to utilizesmaller cells 14 without collisions occurring. As a result, suchembodiments may be able to operate within a smaller workspace. Thus, byincorporating rotation areas 892, particular embodiments of inventorysystem 10 may reduce their overall space requirements and/or provideadditional operational benefits.

FIGS. 19A-19E illustrate example maneuvers that may be performed byparticular embodiments of mobile drive unit 20 when rotating aninventory holder 30 in a rotation area 892. In particular, FIGS. 19A-19Dillustrate various maneuvers that may be completed by mobile drive unit20 to enter a rotation area 892 from a first cell 14 and exit therotation area 892 into a second cell 14 while rotating inventory holder30 so that a particular one of the four faces of inventory holder 30 zis presented to inventory station 50. FIG. 19E illustrates variousmaneuvers that may be performed by mobile drive unit 20 z to allowmobile drive unit 20 z to exit rotation area 892 into any cell 14neighboring rotation area 892. Thus, as shown by FIGS. 19A-19E, inparticular embodiments, mobile drive unit 20 may enter a rotation area892 from any neighboring cell 14, perform an appropriate rotation sothat any face of inventory holder 30 is facing a specific direction, andthen exit into any specific cell 14 neighboring rotation area 892.

FIG. 19A illustrates an example in which mobile drive unit 20 entersrotation area 892 from cell 14 aa, rotates, and exits rotation area 892into cell 14 dd. In particular embodiments, rotation areas 892 may beassociated with a queue in which mobile drive units 20 are expected towait until being granted access to rotation area 892 and also with aninventory station 50 at which the relevant inventory holder 30 will bepresented after exiting the relevant rotation area 892. As a result,mobile drive units 20 may be limited in terms of the cells 14 from whichthey can enter rotation areas 892 and limited in terms of the cell 14into which they can exit rotation areas 892. Thus, FIGS. 19A-19Dillustrate an example of such an embodiment in which mobile drive unit20 z is limited to entering rotation area 892 from cell 14 aa andexiting rotation area 892 into cell 14 dd.

More specifically, in the example shown in FIG. 19A, mobile drive unit20 receives a path 16 into rotation area 892 through cell 14 aa. Mobiledrive unit 20 approaches cell 14 aa along a straight segment 917 a witha first face of inventory holder 30 (labeled as face “920 a” in FIG.19A) facing in the direction of travel, referred to here as the “first”direction. As mobile drive unit 20 is traveling through cell 14 aa,mobile drive unit 20 begins to veer to the left or right so that mobiledrive unit 20 follows an arced segment 918 a into rotation area 892.While mobile drive unit 20 follows arced segment 918 a, the orientationof first face is kept consistent with the direction of travel, as shownin FIG. 19A. As a result, when mobile drive unit 20 reaches the centerof rotation area 892, in the illustrated example, the orientation of thefirst face has changed so that the first face now faces a direction(“referred to here as the “second” direction) somewhere between thefirst direction and a third direction orthogonal to the first direction.In particular embodiments, this second direction equals approximately aforty-five degree rotation from the first direction.

Upon reaching the center of rotation area 892, mobile drive unit 20 mayperform any of a number of rotation maneuvers to facilitate thepresentation of a particular face of inventory holder 30. FIGS. 19A-19Dillustrate examples of these rotation maneuvers. In particular, FIG. 19Aillustrates an example in which mobile drive unit 20 performs a ninetydegree rotation (as indicated by arrow 901 a) in the direction oppositeof the veer mobile drive unit 20 executed to follow arced segment 918 bto orient inventory holder 30 so the first face is presented to anoperator of inventory station 50. Mobile drive unit 20 then moves towardthe cell 14 dd along arced segment 918 b veering in the same directionas the original veer. As a result of the ninety-degree rotation, asecond face (labeled as face “920 b” in FIG. 19A) of inventory holder 30now faces in the direction of travel and mobile drive unit 20 holds theorientation of this second face consistent with the direction of travelas mobile drive unit 20 follows arced segment 918 b.

Furthermore, as mobile drive unit 20 travels arced segment 918 b thisarced path induces an additional rotation in inventory holder 30 thatcomplements the rotation induced in inventory holder 30 while mobiledrive unit 20 traveled arced segment 17 a. In particular embodiments,this rotation is equal to approximately forty-five degrees. As a result,the total rotation induced in inventory holder 30 as a result of mobiledrive unit 20 traveling the arced segments 918 a and 918 b isapproximately ninety degrees. In FIG. 19A, this rotation counteracts therotation performed by mobile drive unit 20 at the center of rotationarea 892 and, as mobile drive unit 20 completes arced segment 918 b, thefirst face of inventory holder 30 is once again facing the firstdirection. Mobile drive unit 20 may then follow another straight pathsegment 17 to inventory station 50. As a result, in FIG. 19A, the firstface of inventory holder 30 is presented to the operator of inventorystation 50.

FIG. 19B illustrates a similar example in which the second face ispresented to the operator of inventory station 50. More specifically, inFIG. 19B, mobile drive unit 20 follows straight path segment 17 a intocell 14 a and follows arced segment 918 a into rotation area 892, asdescribed with respect to FIG. 19A. Upon reaching the center of rotationarea 892, however, mobile drive unit 20 performs aone-hundred-and-eighty-degree rotation (as indicated by arrow 901 b).Mobile drive unit 20 then follows arced segment 918 b into cell 14 dd.As a result of the rotation performed at the center of rotation area892, a third face of inventory holder 30 (labeled as face “920 c” inFIG. 19B) now faces in the direction of travel and mobile drive unit 20holds the orientation of this third face consistent with the directionof travel as mobile drive unit 20 follows arced segment 17 b.

As mobile drive unit 20 travels arced segment 918 b the arced pathinduces an additional rotation in inventory holder 30 as described withrespect to FIG. 19A. In FIG. 19B, this rotation partially counteractsthe rotation performed by mobile drive unit 20 at the center of rotationarea 892 and, as mobile drive unit 20 completes arced segment 17 b, thesecond face of inventory holder 30 is now facing the first direction.Mobile drive unit 20 may then follow straight segment 917 b to inventorystation 50. As a result, in FIG. 19B, the second face of inventoryholder 30 is presented to the operation of inventory station 50.

FIG. 19C similarly illustrates an example in which the third side ispresented to the operator of inventory station 50. More specifically, inFIG. 19C, mobile drive unit 20 follows straight path segment 917 a intocell 14 aa and follows arced segment 918 a into rotation area 892, asdescribed with respect to FIGS. 19A and 19B. Upon reaching the center ofrotation area 892, however, mobile drive unit 20 performs atwo-hundred-and-seventy-degree rotation. Mobile drive unit 20 thenfollows arced segment 918 b into cell 14 dd. As a result of the rotationperformed at the center of rotation area 892, a fourth face of inventoryholder 30 (labeled as face “920 e” in FIG. 19C) now faces in thedirection of travel and mobile drive unit 20 holds the orientation ofthis fourth face consistent with the direction of travel as mobile driveunit 20 follows arced segment 918 b.

As mobile drive unit 20 travels arced segment 918 b the arced pathinduces an additional rotation in inventory holder 30 as described withrespect to FIGS. 19A and 19B. In FIG. 19C, this rotation partiallycounteracts the rotation performed by mobile drive unit 20 at the centerof rotation area 892 and, as mobile drive unit 20 completes arcedsegment 918 b, the third face of inventory holder 30 is now facing thefirst direction. Mobile drive unit 20 may then follow straight pathsegment 918 b to inventory station 50. As a result, in FIG. 19C, thethird face of inventory holder 30 is presented to the operator ofinventory station 50.

FIG. 19D illustrates an example in which the fourth side is presented tothe operator of inventory station 50. More specifically, in FIG. 19D,mobile drive unit 20 follows straight path segment 917 a into cell 14 aaand follows arced segment 918 a into rotation area 892, as describedwith respect to FIGS. 19A and 19B. Upon reaching the center of rotationarea 892, however, mobile drive unit 20 performs no rotation in theexample illustrated by FIG. 19D. Mobile drive unit 20 follows arced path918 b into cell 14 dd. Because no rotation was performed at the centerof rotation area 892, the first face of inventory holder 30 remainsfacing in the direction of travel, and mobile drive unit 20 holds theorientation of the first face consistent with the direction of travel asmobile drive unit 20 follows arced segment 918 b.

As mobile drive unit 20 travels arced segment 918 b the arced pathinduces an additional rotation in inventory holder 30 as described withrespect to FIGS. 19A-19C. Consequently, as mobile drive unit 20completes arced segment 918 b, the fourth face of inventory holder 30now faces the first direction. Mobile drive unit 20 may then followstraight path segment 917 b to inventory station 50. As a result, inFIG. 19D, the fourth face of inventory holder 30 is presented to theoperator of inventory station 50.

Thus, by performing a selected rotation maneuver (including, inparticular circumstances, no rotation) within rotation area 892,particular embodiments of mobile drive unit 20 are capable of achievingany desired orientation for inventory holder 30 upon arriving atinventory station 50. Moreover, when utilized in embodiments ofinventory system 10 that limit or prohibit rotations elsewhere inworkspace 870, the inclusion of rotation areas 892 in select placeswithin workspace 870 allows inventory system 10 to support thepresentation of any face of inventory holders 30 within a significantlysmaller workspace. As a result, the use of the described rotationmaneuvers may provide space-saving and other advantages.

FIG. 19E illustrates how, in particular embodiments, mobile drive units20 can be configured to access rotation areas 892 using any appropriatecombination of neighboring cells 14 as entry and exit points. As shownin FIG. 19E, mobile drive unit 20 may be configured to follow arcedsegment 918 a into rotation area 892, perform an appropriate rotationmaneuver, and then follow one of arced segment 918 b, arced segment 918c, arced segment 918 d, arced segment 918 e, arced segment 918 f, arcedsegment 918 g, and arced segment 918 h to exit into cell 14 bb, cell 14cc, cell 14 dd, cell 14 ee, cell 14 ff, cell 14 gg, and cell 14 hh,respectively. Additionally, mobile drive unit 20 may be configured toexit rotation area 892 following the same path mobile drive unit 20followed entering rotation area 892, that is arced segment 918 a. Thisis indicated in FIG. 19E by the dotted-line curve labeled 918 aa.

Furthermore, while FIG. 19E illustrates an example in which mobile driveunit 20 is configured to enter rotation area 892 through a particularcell 14, specifically cell 14 aa, the example arced segment 918 a inFIG. 19E can be generalized to represent an arced segment 918 enteringrotation area 892 from any of neighboring cells 14 aa-dd. As a result,in a given embodiment of inventory system 10, mobile drive units 20 maybe configured to enter rotation area 892 from and exit rotation area 892to any appropriate cell 14 neighboring rotation area 892. On the otherhand, a given embodiment of inventory system 10 that utilizes rotationareas 892 may also limit the cells 14 that may be used enter and exit aparticular rotation area 892, for example, to control traffic flowaround rotation area 892. Thus, while a particular embodiment ofinventory system 10 may include a rotation area 892 that mobile driveunits 20 are capable of utilizing without constraints as to their entryand exit points, the same or other embodiments of inventory system 10may include rotation areas 892 that mobile drive units 20 are configuredto enter or exit using specific neighboring cells 14.

Thus, in particular embodiments, to present a desired face in a desireddirection and to provide flexibility in choosing entry points into andexit points out of rotation areas 892, mobile drive units 20 may enterrotation areas 892 then perform one or both of a rotation that rotatesboth mobile drive unit 20 and inventory holder 30 and a rotation thatrotates only mobile drive unit 20, in any appropriate order. This mayresult in both mobile drive unit 20 having the appropriate orientationfor mobile drive unit 20 to utilize the desired exit point from therotation area 892 and inventory holder 30 having the appropriateorientation to present the desired face in the desired direction aftermobile drive unit 20 and inventory holder 30 exit rotation area 892. Asa result, in particular embodiments, mobile drive unit 20 may be able toutilize any desired entry and exit points to rotation area 892 and beable to present any desired face of inventory holder 30 in any desireddirection.

FIGS. 20A-20G illustrate an example of how mobile drive unit 20 maytraverse the portions of workspace 870 outside designated rotation areas892 without rotating inventory holders 30. In particular, FIGS. 20A-20Gshow operation of a mobile drive unit 20 as the mobile drive unit 20moves inventory holder 30 from a first position to a second positionalong a portion of a path 16 that includes a ninety-degree turn.Because, in the illustrated embodiment, mobile drive unit 20 is able toturn a corner without rotating inventory holder 30, inventory holder 30may not overlap neighboring cells 14 and/or interfere with inventoryholders 30 in neighboring cells 14 when mobile drive unit 20 changes itsdirection of travel. As a result, inventory system 10 may operate with asmaller workspace and thus mobile drive units 20 configured to operateas shown in FIGS. 20A-20G may provide space-saving benefits.

FIG. 20A shows a starting location of both mobile drive unit 20 i andinventory holder 30 i. Initially, inventory holder 30 i is located at apoint 910 a in the relevant workspace 870, and mobile drive unit 20 i islocated at a point 910 b. As shown by FIG. 20B, mobile drive unit 20 imoves to the location of inventory holder 30 i at point 910 a. At thispoint, mobile drive unit 20 i has yet to dock with inventory holder 30i.

In the illustrated example, mobile drive unit 20 i is configured to dockwith inventory holder 30 i by positioning itself underneath inventoryholder 30 i and raising a docking head of mobile drive unit 20 i. Thus,as indicated by the outline of docking head 110, FIG. 20C illustratesmobile drive unit 20 docking with inventory holder 30 i. Mobile driveunit 20 i then propels itself and inventory holder 30 i in a firstdirection to point 910 b as shown in FIG. 20D.

At point 910 b, mobile drive unit 20 rotates from the first direction toa second direction, as shown in FIG. 20E. As indicated by the outline ofdocking head 110, mobile drive unit 20, in the illustrated example,remains docked with inventory holder 30 throughout the rotation. Forexample, in particular embodiments, mobile drive unit 20 i may, afterdocking with inventory holder 30 i, transport inventory holder 30 i witha rotation lock engaged that prevents mobile drive unit 20 from rotatingindependently from inventory holder 30 i. In such embodiments, whenmobile drive unit 20 i attempts to turn a corner, mobile drive unit 20i, mobile drive unit 20 i may release the rotation lock, allowing theremainder of mobile drive unit 20 to rotate independently from dockinghead 110. Thus, in such embodiments, mobile drive unit 20 may be able torotate while docked with inventory holder 30 but without rotatinginventory holder 30.

After rotating, mobile drive unit 20 i propels mobile drive unit 20 iand inventory holder 30 i in the second direction. As a result, mobiledrive unit 20 moves to point 910 c as shown in FIG. 20F. Depending onthe task mobile drive unit 20 i is completing, mobile drive unit 20 maythen undock from inventory holder 30 i, rotate inventory holder 30 i ina designated rotation area 892 for presentation of a particular face,and/or perform any other appropriate actions to complete its assignedtask.

Although the present invention has been described with severalembodiments, a myriad of changes, variations, alterations,transformations, and modifications may be suggested to one skilled inthe art, and it is intended that the present invention encompass suchchanges, variations, alterations, transformations, and modifications asfall within the scope of the appended claims.

1. A system for transporting inventory items, comprising: a mobile driveunit; a plurality of inventory holders; and a management module operableto: determine an assignment state of a mobile drive unit; in response todetermining that the mobile drive unit is not currently completing atask, select a location for the mobile drive unit based on theassignment state of the mobile drive unit; and transmit information tothe mobile drive unit identifying the selected location.
 2. The systemof claim 1, wherein management module is operable to transmitinformation to the mobile drive unit identifying the selected locationby instructing the mobile drive unit to move to the selected locationand to wait at the selected location until receiving an additionalinstruction.
 3. The system of claim 1, wherein the mobile drive unit isfurther operable to move to the selected location.
 4. The system ofclaim 1, wherein the mobile drive unit is further operable to park atthe selected location until the mobile drive unit receives an additionalinstruction.
 5. The system of claim 1, wherein the management module isoperable to select a location for the mobile drive unit by selecting alocation that is currently storing an inventory holder.
 6. The system ofclaim 1, wherein the management module is operable to select a locationfor the mobile drive unit by selecting a location based on a trafficlevel associated with the location.
 7. The system of claim 1, whereinthe management module is operable to select a location for the mobiledrive unit by selecting a location that is not otherwise available formobile drive units to move through.
 8. The system of claim 1, whereinthe management module is operable to select a location for the mobiledrive unit by selecting a location that is not otherwise available as adestination for mobile drive units.
 9. The system of claim 1, whereinthe management module is operable to select a location for the mobiledrive unit by selecting a location based on a distance from the selectedlocation to a particular inventory holder.
 10. The system of claim 1,wherein the management module is operable to select a location for themobile drive unit by selecting a location based on a distance from theselected location to a particular group of inventory holders.
 11. Thesystem of claim 1, wherein the selected location comprises a firstselected location, and wherein the management module is further operableto: detect a change in a state of an inventory system in which themobile drive unit is operating; determine that the mobile drive unit isstill not completing a task; in response to detecting the change in thestate of the inventory system, select a second location for the mobiledrive unit based on the assignment state of the mobile drive unit; andtransmit information to the mobile drive unit identifying the secondselected location.
 12. The system of claim 11, wherein the managementmodule is operable to detect the change in the state of the inventorysystem by detecting that another mobile drive unit is attempting to movethrough the first selected location.
 13. The system of claim 11, whereinthe management module is operable to detect the change in the state ofthe inventory system by detecting that the first selected destination isa current destination for another mobile drive unit.
 14. A method fortransporting inventory items, comprising: determining an assignmentstate of a mobile drive unit; in response to determining that the mobiledrive unit is not currently completing a task, selecting a location forthe mobile drive unit based on the assignment state of the mobile driveunit; and transmitting information to the mobile drive unit identifyingthe selected location.
 15. The method of claim 14, wherein transmittinginformation to the mobile drive unit identifying the selected locationcomprises instructing the mobile drive unit to move to the selectedlocation and to wait at the selected location until receiving anadditional instruction.
 16. The method of claim 14, further comprisingmoving the mobile drive unit to the selected location.
 17. The method ofclaim 14, further comprising parking the mobile drive unit at theselected location until the mobile drive unit receives an additionalinstruction.
 18. The method of claim 14, wherein selecting a locationfor the mobile drive unit comprises selecting a location that iscurrently storing an inventory holder.
 19. The method of claim 14,wherein selecting a location for the mobile drive unit comprisesselecting a location based on a traffic level associated with thelocation.
 20. The method of claim 14, wherein selecting a location forthe mobile drive unit comprises selecting a location that is nototherwise available for mobile drive units to move through.
 21. Themethod of claim 14, wherein selecting a location for the mobile driveunit comprises selecting a location that is not otherwise available as adestination for mobile drive units.
 22. The method of claim 14, whereinselecting a location for the mobile drive unit comprises selecting alocation based on a distance from the selected location to a particularinventory holder.
 23. The method of claim 14, wherein selecting alocation for the mobile drive unit comprises selecting a location basedon a distance from the selected location to a particular group ofinventory holders.
 24. The method of claim 14, wherein the selectedlocation comprises a first selected location, and further comprising:detecting a change in a state of an inventory system in which the mobiledrive unit is operating; determining that the mobile drive unit is stillnot completing a task; in response to detecting the change in the stateof the inventory system, selecting a second location for the mobiledrive unit based on the assignment state of the mobile drive unit; andtransmitting information to the mobile drive unit identifying the secondselected location.
 25. The method of claim 24, wherein detect the changein the state of the inventory system comprises detecting that anothermobile drive unit is attempting to move through the first selectedlocation.
 26. The method of claim 24, wherein detecting the change inthe state of the inventory system comprises detecting that the firstselected destination is a current destination for another mobile driveunit.
 27. A management module operable to: determining an assignmentstate of a mobile drive unit; in response to determining that the mobiledrive unit is not currently completing a task, select a location for themobile drive unit based on the assignment state of the mobile driveunit; and transmit information to the mobile drive unit identifying theselected location.
 28. A system for transporting inventory items,comprising: means for determining an assignment state of a mobile driveunit; means for selecting, in response to determining that the mobiledrive unit is not currently completing a task, selecting a location forthe mobile drive unit based on the assignment state of the mobile driveunit; and means for transmitting information to the mobile drive unitidentifying the selected location.
 29. A system for transportinginventory items, comprising: a mobile drive unit; a plurality ofinventory holders; and a management module operable to: determine acapability state of a mobile drive unit; select a location for themobile drive unit based on the capability state of the mobile driveunit; and transmit information to the mobile drive unit identifying theselected location.
 30. The system of claim 29, wherein the mobile driveunit is further operable to move to the selected location.
 31. Thesystem of claim 29, wherein the mobile drive unit is further operable topark at the selected location until the mobile drive unit receives anadditional instruction.
 32. The system of claim 29, wherein themanagement module is operable to determine the capability state of themobile drive unit by determining that the mobile drive unit is notcapable of completing a particular type of task.
 33. The system of claim29, wherein the management module is operable to determine thecapability state of the mobile drive unit by determining a charge on abattery associated with the mobile drive unit.
 34. The system of claim33, further comprising an energy station operable to recharge batteriesassociated with mobile drive units, and wherein the management module isoperable to select the location for the mobile drive unit by selecting alocation based on a distance between the location and the energystation.
 35. The system of claim 29, wherein the management module isoperable to: determine the capability state of the mobile drive unit bydetecting a degraded capability of the mobile drive unit, and select alocation for the mobile drive unit based on the capability state of themobile drive unit by selecting a destination for an inventory holderassociated with the degraded capability.
 36. The system of claim 29,wherein the management module is operable to determine the capabilitystate of the mobile drive unit by detecting a fuel level associated withthe mobile drive unit.
 37. The system of claim 29, further comprising anenergy station operable to refuel mobile drive units, and wherein themanagement module is operable to select the location for the mobiledrive unit by selecting a location based on a distance between thelocation and the energy station.
 38. The system of claim 29, wherein themanagement module is operable to determine the capability state of themobile drive unit by determining that the mobile drive unit is unable tocarry an inventory holder.
 39. The system of claim 29, wherein themanagement module is operable to determine the capability state of themobile drive unit by determining that the mobile drive unit is unable todock with an inventory holder.
 40. The system of claim 29, wherein themanagement module is operable to determine a capability state of themobile drive unit that the mobile drive unit is unable to carry aninventory holder.
 41. The system of claim 29, wherein the managementmodule is operable to determine a capability state of the mobile driveunit by detecting that the mobile drive unit needs to be repaired. 42.The system of claim 41, wherein the management module is operable toselect a location for the mobile drive unit by selecting a locationbased on a distance between the location and a repair station.
 43. Thesystem of claim 41, wherein the management module is operable todetermine a capability state of the mobile drive unit by detecting thatthe mobile drive unit needs a particular type of repair.
 44. The systemof claim 43, wherein the management module is operable to select thelocation for the mobile drive unit by selecting a location based on adistance between the location and a repair station operable to performthe type of repair needed by the mobile drive unit.
 45. The system ofclaim 41, wherein the management module is operable to determine acapability state of the mobile drive unit by detecting that the mobiledrive unit needs a particular type of maintenance.
 46. The system ofclaim 45, wherein the management module is operable to select thelocation for the mobile drive unit by selecting a location based on adistance between the location and a maintenance station operable toperform the type of maintenance needed by the mobile drive unit.
 47. Thesystem of claim 29, wherein the management module is operable to selecta location for the mobile drive unit by selecting a location in aworkspace in which the mobile drive unit is operating based on adistance between the selected location and an access point to theworkspace.
 48. The system of claim 29, wherein the management module isoperable to select a location for the mobile drive unit by selecting alocation based on a traffic level associated with the location.
 49. Thesystem of claim 29, wherein the management module is operable to selecta location for the mobile drive unit by selecting a location that is nototherwise available for mobile drive units to move through.
 50. Thesystem of claim 29, wherein the management module is operable to selecta location for the mobile drive unit by selecting a location that is nototherwise available as a destination for mobile drive units.
 51. Thesystem of claim 29, wherein the selected location comprises a firstselected location, and wherein the management module is further operableto: detect a change in a state of an inventory system in which themobile drive unit is operating; in response to detecting the change inthe state of the inventory system, select a second location for themobile drive unit based on the capability state of the mobile driveunit; and transmit information to the mobile drive unit identifying thesecond selected location.
 52. The system of claim 51, wherein themanagement module is operable to detect the change in the state of theinventory system by detecting that another mobile drive unit isattempting to move through the first selected location.
 53. The systemof claim 51, wherein the management module is operable to detect thechange in the state of the inventory system by detecting that the firstselected destination is a current destination for another mobile driveunit.
 54. A method for transporting inventory items, comprising:determining a capability state of a mobile drive unit; selecting alocation for the mobile drive unit based on the capability state of themobile drive unit; and transmitting information to the mobile drive unitidentifying the selected location.
 55. The method of claim 54, whereinfurther comprising moving the mobile drive unit to the selectedlocation.
 56. The method of claim 54, further comprising parking themobile drive unit at the selected location until the mobile drive unitreceives an additional instruction.
 57. The method of claim 54, whereindetermining the capability state of the mobile drive unit comprisesdetermining that the mobile drive unit is not capable of completing aparticular type of task.
 58. The method of claim 54, wherein determiningthe capability state of the mobile drive unit comprises determining acharge on a battery associated with the mobile drive unit.
 59. Themethod of claim 58, wherein selecting the location for the mobile driveunit comprises selecting a location based on a distance between thelocation and the energy station, wherein the energy station is operableto recharge batteries associated with the mobile drive units.
 60. Themethod of claim 54, wherein determining the capability state of themobile drive unit comprises detecting a degraded capability of themobile drive unit, and wherein selecting a location for the mobile driveunit based on the capability state of the mobile drive unit comprisesselecting a destination for an inventory holder associated with thedegraded capability.
 61. The method of claim 54, wherein determining thecapability state of the mobile drive unit comprises determining a fuellevel associated with the mobile drive unit.
 62. The method of claim 54,wherein selecting the location for the mobile drive unit comprisesselecting a location based on a distance between the location and theenergy station wherein the energy station is operable to refuel mobiledrive units.
 63. The method of claim 54, wherein determining thecapability state of the mobile drive unit comprises determining that themobile drive unit is unable to carry an inventory holder.
 64. The methodof claim 54, wherein determining the capability state of the mobiledrive unit comprises determining that the mobile drive unit is unable todock with an inventory holder.
 65. The method of claim 54, whereindetermining the capability state of the mobile drive unit comprisesdetermining that the mobile drive unit is unable to carry an inventoryholder.
 66. The method of claim 54, wherein determining the capabilitystate of the mobile drive unit comprises detecting that the mobile driveunit needs to be repaired.
 67. The method of claim 66, wherein selectingthe location for the mobile drive unit comprises selecting a locationbased on a distance between the location and a repair station.
 68. Themethod of claim 66, wherein determining the capability state of themobile drive unit comprises detecting that the mobile drive unit needs aparticular type of repair.
 69. The method of claim 68, wherein selectingthe location for the mobile drive unit comprises selecting a locationbased on a distance between the location and a repair station operableto perform the type of repair needed by the mobile drive unit.
 70. Themethod of claim 54, wherein determining the capability state of themobile drive unit comprises detecting that the mobile drive unit needs aparticular type of maintenance.
 71. The method of claim 54, whereinselecting the location for the mobile drive unit comprises selecting alocation based on a distance between the location and a maintenancestation operable to perform the type of maintenance needed by the mobiledrive unit.
 72. The method of claim 54, wherein the selecting thelocation for the mobile drive unit comprises selecting a location in aworkspace in which the mobile drive unit is operating based on adistance between the selected location and an access point to theworkspace.
 73. The method of claim 54, wherein selecting a location forthe mobile drive unit comprises selecting a location based on a trafficlevel associated with the location.
 74. The method of claim 54, whereinselecting a location for the mobile drive unit comprises selecting alocation that is not otherwise available for mobile drive units to movethrough.
 75. The method of claim 54, wherein selecting a location forthe mobile drive unit comprises selecting a location that is nototherwise available as a destination for mobile drive units.
 76. Themethod of claim 54, wherein the selected location comprises a firstselected location, and further comprising: detecting a change in a stateof an inventory system in which the mobile drive unit is operating; inresponse to detecting the change in the state of the inventory system,selecting a second location for the mobile drive unit based on thecapability state of the mobile drive unit; and transmitting informationto the mobile drive unit identifying the second selected location. 77.The method of claim 76, wherein the management module is operable todetect the change in the state of the inventory system by detecting thatanother mobile drive unit is attempting to move through the firstselected location.
 78. The method of claim 76, wherein detecting thechange in the state of the inventory system comprises detecting that thefirst selected destination is a current destination for another mobiledrive unit.
 79. A management module operable to: determining acapability state of a mobile drive unit; selecting a location for themobile drive unit based on the capability state of the mobile driveunit; and transmitting information to the mobile drive unit identifyingthe selected location.
 80. A system for transporting inventory items,comprising: means for determining a capability state of a mobile driveunit; means for selecting a location for the mobile drive unit based onthe capability state of the mobile drive unit; and means fortransmitting information to the mobile drive unit identifying theselected location.